우리가 구현한 프로그램을 사용자들이 사용할 때 우리가 예상치 못한 행동으로 오류를 발생시킬 때가 있다. 물론 최고의 방법은 우리가 그때마다 그에 맞는 대체를 하는 것이다. 하지만 동시 사용자가 수만명에 이르고 개발자들은 그에 비해 턱없이 부족하다면? 그래서 우리는 예외 처리라는 방식을 사용한다. 개발자들이 먼저 오류를 일으킬 행동을 예측하고 이에 따라 예외 처리를 해주는 것이다.
최악의 예외 처리
사용자의 오류를 일으킬 행동을 예측하고 이를 catch로 잡아냈다! 그런데 아무런 조치도 취하지 않거나 print만 했다...? 혹은 throw를 했다...? 전자는 오류를 잡느니만 못한 행동이다. 후자는 예외를 잡아서 다른 메소드에게 책임을 전가하는 무책임한 행동이다. 예외를 잡았다면 최대한 빨리 다른 메소드에 이를 넘기지 않고 처리를 해줘야 한다.
아무것도 안해주면 안된다!
좀 심하게 무책임한 예외처리
올바른 예외 처리
그렇다면 어떻게 예외 처리를 해줘야 맞는걸까?
1. 예외 복구
문제를 해결할 수 있는 경우다. 제일 최상의 경우라고 볼 수 있다. 오류를 잡아서 바로 상황에 따라서 문제 상황을 복구한다.
2. 예외 처리 회피
문제를 해결할 수 없는 경우다. 예외처리를 자신이 담당하지 않고 자신을 호출한 쪽으로 던진다. 예를 들어서 앞서 배웠던 템플릿 / 콜백 패턴에서 콜백이 템플릿에게 예외를 던진다. 하지만 이는 템플릿과 콜백처럼 가까운 사이가 아닐 경우 무책임한 책임회피가 될 수 있다.
3. 예외 전환
예외 처리 회피와 마찬가지로 문제를 해결할 수 없어서 예외를 던지지만 새로운 예외로 감싸서 던진다.
1. 의미가 보다 분명한 예외로 바꿔서 던지거나
2. 더 처리하기 쉬운 예외로 바꿔서 던진다.
2번의 예시로는 예외처리를 강제하는 체크 예외를 런타임 예외로 바꿔서 던지는 경우가 있을 것이다. 복구할 수 없는 예외라면 넘기지 않고 최대한 빨리 로그를 남긴 후 런타임 예외로 포장해서 던지는 것이 바람직하다.
.
.
그렇다면 예외처리를 강제하는 체크 예외는 어떤 상황에 사용하는 걸까?
비즈니스적인 의미를 예외에 담고 싶을 때 사용한다. 예를 들어서 atm기에서 잔고 부족으로 출금이 되지 않는 경우가 있다. 이 상황에서는 로그만 남기고 넘어가서는 안될 것이다. 사용자에게 잔액 부족이라는 메세지를 남기고 다시 시도하도록 강제하려면 체크 예외를 사용해야 한다.
SQL 예외
SQL 예외의 경우에는 복구할 수 있는 방법이 있다. 즉, 최대한 빨리 언체크 / 런타임 에러로 전환해서 던져주는 것이 중요하다.
또한 DBMS 마다 사용하는 에러 코드가 다르기 때문에 호환성의 문제가 생길 수 있다. 이런 상황에서는 독립적인 예외로 전환한 뒤에 해당 SQL을 사용한 메소드에서 좀 더 상세하게 예외 전환을 해 줄 필요가 있다.
