[66해빗 페이백 챌린지] 27일차

체크 예외 기본 이해

• 체크 예외 처리

  • try-catch로 잡거나 throws를 명시적으로 선언해 외부로 넘겨야 한다.

• 체크 예외의 장단점

• 장점

  • 개발자가 누락할 수 있는 예외 처리 로직을 컴파일러가 잡아준다.

• 단점

  • 일일히 예외처리를 해야 하므로 코드가 지저분해지고, 예외에 대한 의존관계가 생긴다.

• log.info("예외 처리, message={}", e.getMessage(), e);

  • 로그 남길 때 마지막 파라미터로 예외를 전달하면 예외의 스택 트레이스를 출력해준다.

언체크 예외 기본 이해

• 언체크 예외 처리

  • 언체크 예외는 try-catch로 처리해주지 않아도 throws를 생략할 수 있다(체크, 언체크의 차이)

• 언체크 예외의 장단점

  • 장점
    • 예외 처리를 생략할 수 있어 코드가 깔끔해지고, 예외에 대한 의존관계가 생기지 않는다.
  • 단점
    • 개발자가 예외 처리를 누락하여도 컴파일러가 잡아주지 않는다.

체크 예외 활용

• 예외 활용 전략

  1. 기본적으로는 런타임 예외 활용
  2. 예외 처리가 절대 누락되어서는 안 되는 경우, 체크 예외 활용(예시: 결제 실패, 결제 시 포인트 부족 등)

• 체크 예외의 문제점

  1. 복구 불가능한 예외
     • 복구가 어려운 예외들이 다수다.
  2. 의존 관계 형성

• 예시

  1. 리포지토리에서 체크 예외인 SQLException을 발생시키고 ControllerAdvice에서 처리한다고 가정하자.
  2. 서비스, 컨트롤러는 SQLException가 시스템 예외라서 자신들이 복구할 수 없으므로 throws SQLException하여 예외를 밖으로 던진다.
  3. 그럼 서비스, 컨트롤러에는 자신들이 복구도 할 수 없는 예외에 대한 의존관계가 형성된다.
     • 만약 JDBC에서 JPA로 기술을 바꿔 SQLException이 JPAException으로 바뀐다면?
       • 서비스, 컨트롤러의 코드도 모두 바꿔야 한다(throws SQLException -> throws JPAException, OCP 파괴)
     • 반론) throws Exception으로 예외를 떠넘기면 되지 않나?
       • 그럼 처리할 수 있는 예외들까지도 모두 떠넘기는 결과를 초래(try-catch를 생략하여도 throws Exception이 있어서 컴파일 에러가 발생하지 않기 때문에 개발자가 예외 처리를 누락할 수 있음)

언체크 예외 활용

• 런타임 예외 장점

  • 예외에 대한 의존 관계 제거

• 예시

  1. 앞의 예시에서 리포지토리에서 체크 예외인 SQLException을 런타임 예외인 RuntimeSQLException으로 전환해 던진다고 가정하자.
     • (예외 포함: 예외 전환 시, 기존 예외를 전환하는 예외에 포함해야 예외 추적이 용이)
  2. 그럼 서비스, 컨트롤러는 자신들이 복구 할 수 없는 예외이므로 예외에 대한 별다른 선언을 하지 않음(의존 관계 제거)
  3. 예외가 RuntimeSQLException에서 RuntimeJPAException으로 바껴도 ControllerAdvice만 수정하면 된다. 서비스, 컨트롤러 코드는 영향 없음.

• 시스템 예외처럼 복구가 불가능한 예외는 런타임으로 만들자.

• 복구 가능하면서 반드시 처리해야 하는 예외는 체크 예외로 만들자.

• 런타임 예외 사용이 트렌드

  • 기존에는 체크 예외를 선호
    • 하지만 코드가 난잡해지고, 예외에 대한 의존 문제 발생
  • 최근 라이브러리는 대부분 런타임 예외 사용
    • JPA, Spring도 런타임 예외 사용

• 런타임 예외 문서화

  • 런타임 예외는 try-catch로 잡아주지 않아도 throws를 생략할 수 있어 메소드만 봐서는 어떤 예외가 발생하는지 알 수가 없다. 따라서 반드시 문서에 어떤 예외가 발생하는지 기재를 해야 한다.