자바에서 JSON 데이터를 파싱하는 메서드를 구현하는 도중 IDE에서 다음과 같은 알림?이 왔다.
내용을 해석해 보면 "이 메서드는 예외가 발생할 수 있으니까 네가 반드시 처리해줘야 해" 이런 의미인데 찾아보니 다음과 같은 예외들을 검색해보니 체크 에러라고 부른다고 한다.
또 체크예외(Checked Exception)와는 항상 빠짐없이 쌍으로 등장하는 언체크 예외(Unchecked Exception)라는 것이 있었다.
지금부터 해당 내용을 정리해 볼 것이다.
Error
java.lang.Error는 Throwable의 하위 클래스이며, 주로 JVM에서 발생하는 치명적인 오류를 나타낸다.
메모리 부족(예: OutOfMemoryError)이나 스택 오버플로우(StackOverflowError)처럼 시스템 자체에 문제가 있는 경우 발생하며,
이러한 오류는 일반적으로 애플리케이션 레벨에서 복구할 수 없기 때문에 처리할 필요가 없다.
Checked Exception
RuntimeException을 상속하지 않은 예외들로, 컴파일러가 예외 처리를 강제한다.
주로 복구 가능한 상황에서 발생한다고 보지만, 현실에서는 대부분 복구할 수 없는 경우가 많다.
Unchecked Exception
RuntimeException을 상속한 예외들로, 컴파일 타임에 예외 처리를 강제하지 않는다.
예상치 못한 오류나 프로그래밍 실수에서 발생하며, 복구가 거의 불가능하다.
예: NullPointerException, IllegalArgumentException 등
어떻게 예외를 처리해야 할까?
예외 처리의 방법에는 아래와 같은 방법이 있다.
-
예외 복구: try-catch로 처리
-
예외 처리 회피: throws로 상위로 전파
-
예외 전환: 다른 의미의 예외로 감싸 던지기 (주로 RuntimeException으로)
애플리케이션에서 예외를 처리하는 방법은 다양하지만, 우리는 예외 전환의 관점에서 접근할 수 있다.
특히 복구할 수 없는 예외나 처리할 의미가 명확하지 않은 예외의 경우, 굳이 체크 예외로 처리할 필요가 없다.
예를 들어, 데이터베이스와 관련된 예외는 보통 SQLException처럼 체크 예외로 발생한다. 하지만 우리가 그 예외를 받았을 때 별다른 복구 로직 없이 단순히 에러 메시지를 내려주는 것뿐이라면, try-catch 블록이나 throws 선언만 무의미하게 늘어나는 부작용이 생긴다.
이럴 때는 체크 예외를 런타임 예외(언체크 예외)로 전환해서 던지는 것이 더 나은 선택이 될 수 있다. 실제로 Spring Framework도 DataAccessException이라는 언체크 예외를 사용하여 JDBC나 JPA 등에서 발생하는 모든 DB 예외를 감싸서 던진다. 이를 통해 불필요한 예외 선언을 줄이고, 개발자가 필요한 시점에서만 명시적으로 예외를 처리할 수 있도록 유연함을 제공한다.
따라서, 비즈니스 흐름을 단순하고 깔끔하게 유지하기 위해서는, 복구 불가능한 체크 예외는 언체크 예외로 전환하여 처리하는 방식도 효과적인 예외 처리 전략이 될 수 있다.
