들어가며

• Next API를 개발하면서 try-catch문을 적용하던 중 catch에러 부분에 대한 에러가 신경이 쓰였다.
  

• 해당 에러가 신경이 쓰여 error에 타입을 지정해주었다.
  

• 하지만 error는 any 또는 unknown으로 지정하라고 한다.

• 이렇게 타입을 따로 지정해주지 않는다면, 나는 error안의 message를 꺼내고 싶은데도 계속해서 message속성이 없다고 칭얼댈 것이다.

에러 원인

• 문제 해결에 앞서 error에 타입을 지정해주지 못하는 이유를 알아보았다.

try{
 	throw "error";
  	throw false;
  	throw {
      message: "error",
      code : 400
    }
  
  	await 어떤API함수호출()
} catch(err){
  
}

• 이렇듯 try문안에서는 여러 타입으로 throw가 될 수 있고, catch는 여러 타입을 받아내야 한다.

해결방법

1. any로 타입 강제변경

 catch (error: any) {
    res.status(400).json({ message: error.message });
 }

• 하지만 이는 타입스크립트를 쓰는 의미가 없으므로 PASS

2. 타입 단언하기 (as)

catch (error) {
  const err = error as TFirebaseAuthError;
  res.status(400).json({ message: err.message });
}

• as키워드를 통해 error를 TFirebaseAuthError타입이라고 단언해버리는 것이다.
• 하지만 as 또한 any만큼 TS의 의미를 퇴색하게 만든다.

3. 타입 가드하기 (instanceof)

catch (error) {
  if (error instanceof FirebaseAuthError) {
    res.status(400).json({ message: error.message });
  } else {
    res.status(400).json({ message: "undefined error" });
  }
}

• instanceof키워드로 해당 타입이 일치한다면, 그에 응하는 응답을 내려줄 수 있다.

주의점

instanceof할 타입은 interface나 type이어서는 안된다.

• 그 이유를 알아보니, 컴파일 과정 이후에 코드가 남느냐의 문제였다.
• interface나 type은 TS의 고유문법이기에, TS -> JS로 컴파일되면 코드가 사라지게 된다.
  • 컴파일이후에는 그렇기에 error instanceof (빈껍데기)처럼 되버리는 것이다.
• 이에 대한 해결방법은 클래스를 에러객체로 사용하는 것이다.
  • 클래스는 js로 컴파일이 되어도 사라지지 않기 때문이다.

class CustomError_Class extends Error {
   response?: {
      data: any;
      status: number;
      headers: string;
   };
}

...

if(error instanceof CustomError_class) {
 	... 
}

참고사이트

• 타입스크립트 커스텀 Error 처리하기