체크 예외, 언체크 예외

1. 체크 예외 (Checked Exception):
   • 체크 예외는 컴파일러가 강제로 예외 처리를 요구하는 예외
   • RuntimeException 클래스를 상속하지 않은 예외들이 체크 예외에 해당
   • 주로 외부 리소스 접근이나 네트워크 통신과 같은 입출력 작업에서 발생
   • 예외 처리를 강제함으로써 코드 안정성을 높이고 예외 발생 시 적절한 대응을 유도
2. 언체크 예외 (Unchecked Exception):
   • 언체크 예외는 컴파일러가 예외 처리를 강제하지 않는 예외
   • RuntimeException 클래스를 상속한 예외들이 언체크 예외에 해당
   • 주로 프로그램 실행 중 발생하는 예기치 않은 상황이나 오류를 나타냄
   • 개발자의 실수나 프로그램 논리 오류에 의해 발생하는 경우가 많음
   • 명시적인 예외 처리를 강제하지 않기 때문에 코드 작성 시 예외 처리에 대한 부담이 적음

 

 

 

체크 예외와 언체크 예외를 살펴보면 보통 체크 예외가 안정성이 높고 무조건 체크 예외를 해야 하는게 아닌가하는 마음이 들 것이다.

나도 마찬가지로 강의를 보기 전까지는 저렇게 생각하고 코드를 짰었다..

 

하지만 체크 예외의 단점을 살펴보니 생각 없이 체크 예외를 던지는 건 위험하다는 걸 알게 됐다.

 

체크 예외의 대표적인 단점은 SQL 예외다.

 

• 처리할 수 없는 SQL 예외의 경우, 컨트롤러까지 예외를 던지는 문제가 발생할 수 있다.(throws..throws..throws..)
• 이러한 예외들은 JDBC에 의존하게 되며, 만약 JPA로 전환하는 경우에는 모든 SQL 예외를 JPA 예외로 바꿔줘야 한다.
• 이로 인해 컨트롤러는 처리할 수도 없는 예외인데 거기에 의존하게 되는 문제가 발생하는 것이다!!!!

 

 

따라서, 이러한 상황에서는 런타임 예외로 변환하는 것이 좋다.

• 예를 들어, try-catch 블록에서 SQL 예외를 잡고 새로운 런타임 예외로 던지는게 대표적인 방법!
• 이때 !! 런타임 예외를 명시하는 것이 중요하며, 놓치기 쉬우므로 주석, 문서화는 꼭 해주자!!!
• 그리고
  1. try-catch 블록에서 SQL 예외를 잡아서 런타임 예외로 바꿀 때, 기존 예외를 파라미터로 넣어주어야 한다.
     이렇게 함으로써 로그에서 기존 예외도 함께 확인할 수 있다!! 밑에 코드 느낌으로..!!
     => 만약 기존 예외를 안넣어주면 런타임 익셉션이 발생했을 때 도대체 이게 왜 발생했는지 알 수 없어진다..!!
           스택트레이스 등을 알기 위해 필수..!!

try-catch를 할 때

catch(SQLException e){

throw new CustomRuntimeException(e)

}

* 추가로 런타임 예외는 놓칠수있으니 주석, 문서화가 필수다!!

 

 

추가적인 단점으로 체크된 예외의 사용은 인터페이스에도 의존하게 된다.

• 예를 들어, 구현체에서 체크된 예외를 사용하는 경우, 인터페이스에서도 해당 예외를 선언해주어야 한다.
• 인터페이스는 원래 종속되지 않아야 하는데, 체크된 예외로 인해 종속 되는 문제가 발생하게 되는 것!!

따라서 위와 같은 이유로, 무지성으로 체크된 예외를 사용하는 것은 바람직하지 않다..!!