배포 전에 unknown 에러를 피하기

catch 블록에서 error를 any로 받고 바로 error.message를 접근했다가 배포 환경에서 화면이 깨진 경험이 있다. error가 객체가 아닐 수도 있다는 걸 간과했다.

catch 블록에서 error는 unknown

JavaScript에서 throw 될 수 있는 건 Error 객체뿐만 아니다:

throw 'string error';
throw 42;
throw null;
throw { custom: 'object' };

모두 유효한 코드다. 따라서 catch 블록에서는 error를 unknown으로 받아야 한다.

안전한 error 타입 가드

먼저 error가 Error 객체인지 확인하자:

try {
  // some code
} catch (error) {
  if (error instanceof Error) {
    console.error(error.message);
  } else {
    console.error('Unknown error:', error);
  }
}

더 복잡한 경우

HTTP 요청 에러나 커스텀 에러 객체를 다룰 때는 더 신경 써야 한다:

function getErrorMessage(error: unknown): string {
  if (error instanceof Error) return error.message;
  if (typeof error === 'string') return error;
  if (typeof error === 'object' && error !== null && 'message' in error) {
    return (error as any).message;
  }
  return 'Unknown error occurred';
}

빌드 시 타입 체크

npm run build

빌드할 때 npx tsc --noEmit으로 타입 검사만 먼저 하는 것도 좋다. 런타임에 터지는 에러를 미리 잡을 수 있다.

로그에 기록할 때

error를 로그에 남길 때도 안전하게:

const errorLog = error instanceof Error
  ? { message: error.message, stack: error.stack }
  : { raw: error };

console.error(JSON.stringify(errorLog));

배포 환경에서의 문제

로컬에서는 대부분의 error가 Error 객체라서 문제를 못 본다. 하지만 배포 환경에서는:

• 네트워크 라이브러리에서 다양한 형태의 에러가 날 수 있다
• 제3의 서비스 API에서 예상 못한 형태의 에러가 올 수 있다
• 사용자 입력이나 타사 스크립트에서 뜻밖의 에러가 나올 수 있다

작은 타입 체크가 배포 후 골치 아픈 버그를 방지한다.