필수 지식: 예외 처리 전략과 원칙

SQLException 에 대한 고민

1. SQLException 은 복구 가능한 예외인가.
   • 99% 의 SQLException 은 코드 레벨에서 복구할 방법이 없다.
   • 원인
     • 프로그램의 오류 혹은 개발자의 부주의
     • 통제할 수 없는 외부 상황

       • DB 커넥션 풀이 꽉 차서 DB 커넥션을 가져올 수 없는 경우

       • 잘못된 SQL 문법

       • 제약 조건 위반

       • DB 서버 다운..

       • 네트워크 불안정

       • 기타 등등…

2. 시스템 예외라면 당연히 애플리케이션 레벨에서 복구할 수 없다.
   • 관리자/개발자에게 예외 발생 여부를 알리는 방법이 유일
3. 애플리케이션 코드의 버그나 미처 다루지 못한 범위를 벗어난 값 때문에 발생한 예외 역시 복구 불가
4. ISERT 문에 넣을 파라미터 값을 미리 체크하지 않아 발생한 SQLException?
   • 입력 단계에서 검증을 강화해야 한다는 사실을 개발자가 빨리 인식할 수 있도록 발생한 예외를 전달하는 것 말곤 할 수 있는 게 없다.

⇒ DAO 밖에서 SQLException 을 다룰 가능성은 거의 없으므로 가능한 언체크/런타임 예외로 전환해야한다.

스프링의 JdbcTemplate 은 이 예외 처리 전략을 따르고 있다.

• JdbcTemplate 템플릿과 콜백 안에서 발생하는 모든 SQLException

  → 런타임 예외인 DataAccessException 으로 포장해서 던져준다.

• JdbcTemplate 을 사용하는 UserDao 메서드

  : 필요한 경우에만 런타임 예외, DataAccessException 을 잡아서 처리하고 그 외는 무시

• DataAccessException 는 런타임 예외

  • 해당 예외를 던지는 메서드를 사용할 때 이를 다시 잡거나 던질 의무는 없다.
  • update(), queryForInt(), query() …

그 밖에도 스프링 API 메서드에 정의된 대부분 예외는 런타임 예외

⇒ 발생 가능한 예외가 있다고 해서 이를 처리하도록 강제하지 않는다.