체크 예외, 언체크 예외

Java의 예외는 크게 체크 예외(Checked Exception)와 언체크 예외(Unchecked Exception)로 나눌 수 있다.

체크 예외(Checked Exception)

Exception 클래스를 상속받으며, RuntimeException을 상속하지 않는 예외들이다.
컴파일 시점에서 확인되며, 반드시 예외 처리를 해야 한다.
예외 발생 가능성이 있는 메소드를 사용할 때는 try-catch로 감싸거나 throws를 통해 예외를 선언해야 한다.
컴파일 시점에 확인된다.

컴파일 시점 : IDE에서 빌드할 때. Maven/Gradle로 빌드할 때 => 코드를 기계어로 변환하는 과정

언체크 예외(Unchecked Exception)

RuntimeException 클래스를 상속받는 예외들
컴파일 시점에서 확인되지 않으며, 예외 처리가 필수가 아니다.
RuntimeException은 프로그래밍 오류를 나타내기 위한 것이므로, 프로그램의 정상적인 실행을 방해하는 예외들은 보통 피할 수 없거나(NullPointerException), 복구가 불가능한 경우가 많다. 모든 가능한 RuntimeException을 컴파일러가 체크하도록 하면 프로그램 작성이 매우 번거로워질 수 있다.

// 만약 RuntimeException도 체크된다면
public void method() throws NullPointerException, ArrayIndexOutOfBoundsException, 
    IllegalArgumentException, NumberFormatException {
    // 거의 모든 메서드에 이런 선언이 필요할 것
}

따라서 자바는 실행 시점에서 확인될 수 있는 프로그래밍 오류는 언체크 예외로 분류하고, 비즈니스 로직상 발생할 수 있는 예외 상황은 체크 예외로 분류했다.

실행 시점(Runtime) : 서버를 실행할 때 (java -jar app.jar). API를 실제로 호출할 때 => 변환된 코드를 JVM에서 구동하는 과정

먼저 전체 소스코드가 컴파일됨 (컴파일 시점)
서버가 시작되며 컴파일된 코드가 메모리에 로드됨 (서버 실행)
API 호출 등으로 특정 코드가 실행됨 (실행 시점)

주요 차이점

1. 예외 처리 의무

• 체크 예외: 반드시 예외 처리 필요
• 언체크 예외: 명시적인 예외 처리가 선택적

2. 트랜잭션 롤백

• 체크 예외: 기본적으로 롤백되지 않음
• 언체크 예외: 기본적으로 롤백됨

3. 사용 목적

• 체크 예외: 비즈니스 로직에서 발생할 수 있는 예외 처리
• 언체크 예외: 프로그래밍 오류를 나타내는 예외 처리

모든 예외를 언체크 예외로 처리하는 방식은 충분히 유효한 전략이며, 많은 현대적인 프레임워크와 라이브러리에서도 이 방식을 채택하고 있습니다. 다만, 이를 효과적으로 사용하기 위해서는 명확한 예외 처리 정책, 문서화, 그리고 팀 내 일관된 컨벤션이 필요합니다.