얼마전 포프티비를 보다가 문화 충격을 경험했다. 익셉션을 쓰지마라.. 나 역시 실무를 하면서 익셉션을 쓴 적은 거의 없었지만, 마음 한켠으로는 익셉션을 언제 써야하는지에 대한 막연한 두려움을 가지고 있었다.
고수가 된다면 현란한 에러 throw, 현란한 catch 로 멋있는 코드를 작성하지 않을까? 라는 엉뚱한 생각도 해봤고, 나는 왜 익셉션을 제대로 활용할 줄 모르는가? 라는 애매한 생각이 내 머릿속을 꾸준히 지배했던것 같다.
익셉션을 꼭 써야하는가?에 대한 약간의 의문점 또한 가지고 있었다. 그러던 차에, 이 동영상을 보고 많은 위안이 되었고 내가 앞으로 익셉션을 어떻게 대해야 할지의 방향감각이 생기게 되었다.
동영상의 중요내용을 간략히 정리하자면 아래와 같다.
- DB 커넥션, 파일 등의 외부 익셉션은 처리할 수밖에 없다.
- 그러나 내가 만든 서비스에서 익셉션이 발생했다는 것은 상태 자체가 Garbage 이므로 다음 코드를 진행한다는 자체가 말이 안된다.
- 익셉션이 나면 프로그램이 뻗는 정도는 아니지만 적당히 깨지도록 해야한다. 따라서 Exception Safe Programming 하지 말고 해당 모듈 자체에서 try-catch 하여 로직을 멈추어 그 자리에서 에러 메시지를 반환하고 로그를 남기는 방식으로 Exception Masking을 하라.
- 그래도 익셉션 발생 시 프로그램이 안전하게 돌아가도록 핸들링(Exception Safe Programming) 하는것은 생각해볼만 하나, 그것을 하기엔 너무 힘들다. 익셉션 핸들링은 가급적 하지 말자.
이 개념을 내 상황에 비추어 볼 때, 내가 현재 회사에서 API 를 제작하는 과정이 결코 옳은 것은 아니라고 생각든다. 회사의 컨벤션에 맞게 상황에 따른 커스텀 익셉션 throw 하니까.. 이는 익셉션을 Masking을 하는게 아니라 상위에서 처리해달라는 의미가 되니까 옳지 않은 것이다.
영상의 내용에 맞게 코드를 짠다면, 익셉션이 발생하는 구간을 마스킹해서 그 소스에서 Response 를 바로 보내도록 소스를 작성해야하지 않을까 싶다. 아직은 정확하지 않아 더 검토를 해야할것 같다.
또 이런 개념을 바탕으로 오늘 Javascript 문서를 읽던 중, 프론트엔드 개발자인 나에게 보다 더 흥미로운 것을 발견했다. Promise Unhandled Exception에 관한 문서에서 또한 이런 컨셉을 다루고 있었다.
Promise 를 처리할 때 에러를 회복할 방법이 없다면 catch 를 사용하지 않아도 된다고 한다. 프론트엔드에서도 Promise 에 익셉션이 발생하면 깨져도 된다고 말하고 있다. 대신 unhandledrejection 이벤트를 등록하여 사용자 혹은 서버에 알려서 애플리케이션이 아무런 설명도 없이 '그냥 죽는걸' 방지하라고 설명하고 있다.
window.addEventListener('unhandledrejection', function(event) {
// 이벤트엔 두 개의 특별 프로퍼티가 있습니다.
alert(event.promise); // [object Promise] - 에러를 생성하는 프라미스
alert(event.reason); // Error: 에러 발생! - 처리하지 못한 에러 객체
});
new Promise(function() {
throw new Error("에러 발생!");
}); // 에러 처리 핸들러, catch가 없음