에러가 발생할 가능성이 있다면 누군가는 그것에 맞닥뜨릴 것이다. 설계자는 모든 가능성을 미리 상정하며 에러를 막고, 발생 시 영향을 최소화하도록 설계해야만 한다. -도널드 A. 노먼
코드가 실패할 것이라는 가정
어떤 개발자들은 마치 어떤 에러도 발생하지 않을 것처럼 코드를 작성하는 경향이 있다. 이러한 사람들은 결국 에러를 추적하면서 많은 시간을 보내게 된다. 하지만 이러한 경향을 어찌보면 당연해 보이기도 한다. 누가 실패할 코드를 작성하고 싶어하겠는가? 누가 잘못된 일을 할 것이라는 생각을 하면서 프로젝트를 시작하겠는가?
하지만 결국 모든 개발자는 에러를 마주하게 된다. 그렇다면 이렇게 생각해보는 것은 어떨까? 에러는 반드시 발생한다. 그렇다면 코드를 작성할 때, 어떻게 접근 방법을 바꿀 수 있게 될까?
에러 던지기
자바스크립트를 통한 개발을 하다보면 에러를 만나게 된다. 하지만 이러한 에러메세지들은 너무나 간결하거나, 충분한 정보를 제공하지 못하는 경우가 흔하다. 때문에 우리는 스스로 에러를 던짐으로써 이러한 문제들을 해결할 수 있는것이다.
throw new Error("Something bad happened.");가장 간단한 방식의 에러던지기 만으로도 완전히 다른 정보를 알릴 수 있는 것이다.
일반적으로 널리 알려진 try-catch-finally 문으로 에러를 핸들링 할 수도 있다.
try{
// 에러가 발생할수도 있는 코드
}catch(err){
// 에러를 핸들링 하는 부분
}finally{
// 에러발생 유무와 상관없이 실행되어야 하는 부분
} 주의해야하는 점으로는, try-catch-finally는 동기적으로 동작한다는 점이다. setTimeout등으로 대표되는 비동기요청의 경우는 try-catch-finally 블록을 떠나고 나서 실행되게 된다. 즉, 비동기요청의 예외를 잡기 위해서는 해당 함수 내부에 try-catch-finally를 구현해야 한다.
try {
setTimeout(function() {
throw new Error; // 에러발생
}, 1000);
} catch (err) {
// 하지만 catch 블록에서 잡아낼 수 없음
}언제 에러를 던질까?
에러를 던지는 방법 자체는 단순한 공식이라고 볼 수 있다. try-catch-finally로 통용되는 에러핸들링 방식도 그러하다. 그렇다면 우리는 언제 에러를 던져야 하는 것일까?
javascript에는 여러가지 에러 종류가 있다. 대표적으로 여러분들이 만나게 되는 에러로는 아래와 같은 것들이 있다.
ReferenceError // 오브젝트가 예상되었지만 가능하지 않을 때. ex) null에 대한 참조
TypeError // 변수가 예상된 타입이 아닐 때.
RangeError // 숫자가 범위를 넘을 때
...에러들을 보고 이렇게 생각할 수도 있다.
자바스크립트는 기본적으로 타입이나 인수 확인을 하지 않는다. 때문에 모든 함수에 대해서 그것을 확인하는 구문을 삽입해야만 하는것이 아닌가?
지금은 물론 Typescript라는 훌륭한 대체재를 통해서 이를 해결할 수 있다. 하지만 순수한 Javascript를 통해서 이를 핸들링 하려하는 것은 비현실적이며, 성능에 영향을 끼칠 수 있다. 핵심은 특별한 방법으로 실패할 것 같은 코드 부분에서만 에러를 던지는 것이다. 즉, 사실상 이미 에러가 발생한 것이나 다름없는 부분에만 에러를 던진다.
커스텀에러
Js에서 기본적으로 제공해주는 에러만으로는 표현될 수 없는 에러나, 특수한 상황에서 필요한 에러들이 필요할 수 있다. 이를 통해 의도적으로 던져진 에러와 브라우저에서 던져진 예측하지 못한 에러를 쉽게 구별할 수도 있다. 기존의 Error 클래스를 상속하고, 간단한 패턴을 지킴으로써 쉽게 커스텀 에러를 생성할 수 있다.
class MyError extends Error{
constructor(message){
super(message);
}
}
throw new MyError("Hello My Error!");이러한 커스텀에러는 내장 에러와 구별하기 위해 사용한다면, 커스텀에러를 일종의 에러타입의 기준으로 사용할 수도 있는 것이다.
try{
... //do something
}catch(err){
if(err instanceof MyError){
... // Custom Error
}else{
... // Basic Error
}
}결론
에러와 예외처리는 일반적으로 즐거운 주제는 아니다. 하지만 궁극적으로 에러의 원인을 찾고 해결하는 것에 너무 많은 시간을 쏟지 않고 싶다면, 에러핸들링은 선택이 아니라 필수적인 요소라 해야 할 것이다.
