지금까지 살펴본 예외의 종류와 처리방법 등을 기준으로 일관된 예외 처리 전략을 정리해보자

런타임 예외의 보편화

체크 예외는 복구할 가능성이 조금이라도 있는 상황이기 때문에 catch 블록이나 throws 선언을 강제한다.

• 예외가 발생할 가능성이 있는 메서드를 사용하는 개발자 실수 방지를 위함

애플릿, AWT, Swing… 을 사용한 독립형 애플리케이션

• 통제 불가능한 시스템 예외라 해도 애플리케이션 작업이 중단되지 않게 하고 상황 복구

  ex. 워드 파일 열기 기능

  • 사용자 입력 파일을 못찾는다고 애플리케이션을 종료시킬 수 없다.

자바 엔터프라이즈 서버 환경

• 수많은 사용자가 동시에 요청을 보내고 각 요청이 독립적인 작업으로 취급된다.

  • 하나의 요청 처리 중 예외 발생 시 해당 작업만 중지

    (독립형 애플리케이션과 달리) 서버의 특정 계층 예외 발생 시 작업 일시 중지

    • 사용자와 커뮤니케이션하며 예외 상황 복구 불가

정리

1. 애플리케이션 차원에서 예외 상황을 미리 파악하고 예외가 발생하지 않도록 차단하자.
   1. 만약, 프로그램 오류나 외부 환경으로 인한 예외
      • 해당 요청 작업을 빠르게 취소하고 서버 관리자나 개발자에게 통보
2. 자바 환경이 서버로 이동하면서 체크 예외 활용도와 가치는 떨어지고 있다.
   1. 예외 블랙홀, 무책임한 throws 남용
   2. 대응 불가능한 체크 예외라면 빨리 런타임 예외로 전환해서 던지자.
3. 최근 표준 스펙 혹은 오픈소스 프레임워크는 API 가 발생시키는 예외를 언체크 예외로 정의하는 것이 일반화
   1. 과거) 복구 가능성이 있다? → 체크 예외
   2. 현재) 항상 복구할수 있는 예외가 아니다 → 언체크 예외
      • 필요하다면 언제든 잡아서 복구/처리 가능
      • 하지만 대개는 복구 불가능한 상황 → RuntimeException 으로 포장해서 던지기
      • 아예 API 차원에서 런타임 예외를 던지게 만들자

add() 메서드의 예외처리

add() 가 던지는 체크 예외

: DuplicatedUserIdException, SQLException

• 충분히 복구 가능한 예외
  • 아이디 중복으로 인한 SQLException
  • DuplicatedUserIdException 로 전환하여 의미를 명확하게
  • add() 메서드를 사용하는 쪽에서 잡아서 대응할 수 있도록