자바는 문제 상황을 알리는 타입(throwable)으로 검사 예외(checked exception), 런타임 예외(unchecked exception), 그리고 Error를 제공합니다.
1. Checked Exception
- RuntimeException 클래스를 상속하지 않은 예외
- 컴파일러가 강제로 예외 처리를 요구
- 예외를 try-catch문으로 감싸지 않거나 상위 계층으로 던지지 않을 경우 컴파일 에러 발생
- ex) IoException, SQLException, etc.
2. Unchecked Exception
- RuntimeException을 상속한 클래스
- Checked Exception과 달리 try-catch문으로 감싸지 않거나 상위 계층으로 던지지 않더라도 컴파일 에러 발생하지 않음
- 컴파일러가 예외 처리를 강제하지 않음
- ex) NullPointerException, ArithmeticException, etc.
3. Error
- 시스템 자원의 부족이나 불량으로 인해 발생하는 심각한 문제
- 프로그램이 진행할 수 없는 치명적인 상황을 나타내며, 일반적으로 프로글매이 복구할 수 없는 상황
- ex) OutOfMemoryError, StackOverflowError, etc.
Checked Exception이 적합한 상황
- 호출한 쪽에서 복구하리라 여겨지는 상황이라면 Checked Exception을 사용하자
- 메서드 선언에 포함된 검사 예외 각각은 해당 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주는 것
- Checked Exception과 Unchecked Exception을 구분하는 가장 기본적인 규칙
- 일반적으로 Checked Exception 예외가 발생했을 경우 복구 전략을 활용하여 복구할 수 있는 경우는 많지 않음
- 보통 CheckedException을 catch 하고 커스텀 예외로 선언한 Unchecked Exception을 발생시켜 예외를 다시 전파하는 것이 현실적인 해결 방법
Unchecked Exception이 적합한 상황
- 프로그래밍 오류를 나타낼 때는 Unchecked Exception을 사용
- Unchecked Exception은 대부분 전제조건을 만족하지 못했을 때 발생
- 여기서 `전제조건 위배`란 단순히 클라이언트가 해당 API의 명세에 기록된 제약을 지키지 못했다는 뜻
- ex) 배열의 인덱스는 [0, 배열의 사이즈)여야 하는데 범위에 해당하지 않는 인덱스를 접근 시도하는 경우 ArrayIndexOutOfBoundsException 예외 발생
결론은 예외가 복구 가능하다고 믿는다면 Checked Exception을, 그렇지 않을 경우 Unchecked Exception을 사용하는 것을 권장합니다.
Error와 Throwable을 대하는 자세
- Error는 보통 JVM 자원이 부족하거나 불변식이 깨지는 등 더 이상 애플리케이션 수행을 지속할 수 없을 때 사용
- 업계에 널리 퍼진 규약으로 Error 클래스를 상속해 하위 클래스를 만드는 일은 자제해야 함
- Error는 상속하지 말아야 하고, throw로 직접 던지지도 말아야 함
- Throwable은 Exception, RuntimeException, 그리고 Error의 상위 클래스
- Throwable은 절대 직접 사용하지 말자!
- Throwable은 정상적인 Checked Exception보다 나을 것이 하나도 없으면서 API 사용자에게 혼란을 가할 뿐
예외도 객체
- 예외도 어떠한 메서드를 정의할 수 있는 객체
- 예외의 메서드는 주로 해당 예외가 발생한 상황에 대한 정보를 코드 형태로 전달하는 데 사용
- 특히 Checked Exception의 경우, 예외 상황을 해결하기 위해 필요한 정보를 알려주는 메서드를 함께 제공 가능
코드 부연 설명
- 존재하지 않는 파일을 읽으려고 시도할 때 `FileProcessingException` 발생
- 해당 예외를 처리할 때 해결하기 위해 필요한 정보를 알려주는 메서드인 `resolveIssue()` 메서드를 호출
참고
이펙티브 자바
반응형
'JAVA > Effective Java' 카테고리의 다른 글
[아이템 72] 표준 예외를 사용하라 (0) | 2024.03.25 |
---|---|
[아이템 71] 필요 없는 검사 예외 사용은 피하라 (0) | 2024.03.25 |
[아이템 69] 예외는 진짜 예외 상황에만 사용하라 (0) | 2024.03.21 |
[아이템 68] 일반적으로 통용되는 명명 규칙을 따르라 (0) | 2024.03.20 |
[아이템 67] 최적화는 신중히 하라 (0) | 2024.03.19 |