아이템 70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라

[JoisFe]

70. 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라

throwable (문제 상황을 알리는 타입)

• 자바는 throwable로 검사 예외, 런타임 예외, 에러 이렇게 3가지를 제공
• 이 3가지를 언제 무엇을 사용해야하는지 헷갈리는 경우가 있음

검사 예외, 런타임 예외, 에러 3가지를 언제 무엇을 사용할지 지침

• 앞으로의 지침이 100% 명확한 것은 아님!!

1. 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용

• 이 지침이 검사와 비검사 예외를 구분하는 기본 규칙
• 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 됨
• --> 메서드 선언에 포함된 검사 예외 각각은 그 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알림
• (API 설계자는 API 사용자에게 검사 예외를 던져 그 상황에서 회복시키라 요구)
• 물론 사용자는 예외를 잡기만 하고 별 조치를 취하지 않을 수 있음 다만 이는 좋지 않음 (아이템 77 참고)

비검사 throwable 2 가지

1. 런타임 에러
2. 에러

• 공통점 : 프로그램에서 잡을 필요가 없거나 혹은 통상적으로는 잡지 말아야 함
• 프로그램에서 비검사 예외 혹은 에러를 던졌다는 것은 복구가 불가능하거나 더 실행해봐야 득보다 실이 더 많다는 뜻
• 해당 throwable을 잡지 않은 스레드는 적절한 오류 메시지를 내뱉으며 중단됨

2. 프로그램 오류를 나타낼 때는 런타임 예외를 사용

• 런타임 예외의 대부분 경우 전제조건을 만족하지 못한 경우

전제조건 위배

• 단순히 클라이언트가 해당 API의 명세에 기록된 제약을 지키지 못했다는 뜻
• ex) ArrayIndexOutOfBoundsException : 배열의 인덱스는 0에서 배열 크기 -1 사이 여야하는 전제조건을 지키지 못한 것

제약은 조건에서 문제가 하나 있다면 복구할 수 있는 상황인지 프로그래밍 오류인지가 항상 명확히 구분되지 않음

• ex) 자원 고갈은 말도 안 되는 크기의 배열을 할당해 생긴 프로그래밍 오류일 수도 있고, 진짜로 자원이 부족해서 발생한 문제일 수 있음. 만약 자원이 일시적으로 부족하거나 수요가 순간적으로 몰린 것이라면 충분히 복구 가능
• 즉 복구될 수 있는지 없는지의 판단의 API 설계자의 몫

위의 판단을 내리지 못할 경우 즉 확신하기 어렵다면 아마도 비검사 예외를 선택하는 편이 나음

• 해당 이유는 아이템 71 참고

3. 구현하는 비검사 throwable은 모두 RuntimeException의 하위 클래스여야 함 (직접적이든 간접적이든)

• 에러는 보통 JVM이 자원 부족, 불변식 깨짐 등 더 이상 수행을 계속할 수 없는 상황을 나타낼 때 사용
• 자바 언어 명세가 요구하는 것은 아니지만 업계에 널리 퍼진 규약
• Error 클래스를 상속해 하위 클래스를 만드는 일은 자제 (Error를 상속하지 말아야)
• 또한 throw 문으로 직접 던지는 일도 없어야 함 (AssertionError 경우 예외)

throwable을 언제 사용?

• Exception, RuntimeException, Error을 상속하지 않는 throwable을 만들 수도 있음
• 자바 언어 명세에서 이런 throwable을 직접 다루지는 않지만 암묵적으로 일반적인 검사 예외 (Exceptiond의 하위 클래스 중 RuntimeException을 상속하지 않은) 처럼 다룸

throwable은 이로울 게 없으니 절대 사용하지 말아야 함!!!!!!

• throwable 경우 정상적인 검사 예외보다 나을 게 하나도 없으면서 API 사용자를 헷갈리게 할 뿐
• API 설계자 또한 예외 역시 어떤 메서드라도 정의할 수 있는 완벽한 객체라는 사실을 잊곤 함...

예외의 메서드

• 예외의 메서드 경우 주로 그 예외를 일으킨 상황에 대한 정보를 코드 형태로 전달하는데 쓰임
• 이런 메서드가 존재하지 않는다면 프로그래머들은 오류 메시지를 파싱해 정보를 빼내야하는 불편함을 겪게 될 것임 (이러한 습관은 매우 나쁨 아이템 12. toString을 항상 재정의하라 #32 참고)
• throwable 클래스들 대부분은 오류 메시지 포맷을 상세히 기술하지 않는데 이는 JVM이나 릴리스에 따라 포맷이 달라질 수 있기 때문임
• --> 메시지 문자열을 파싱해 얻은 코드는 깨지기 쉽고 다른 환경에서 동작하지 않을 수 있음

검사 예외와 예외의 메서드

• 검사 예외는 일반적으로 복구할 수 있는 조건일 때 발생
• --> 호출자가 예외 상황에서 벗어나는 데 필요한 정보를 알려주는 메서드를 함께 제공하는 것이 중요

정리

• 복구할 수 있는 상황이면 --> 검사 예외
• 프로그래밍 오류라면 --> 비검사 예외
• 확실 하지 않다면 --> 비검사 예외
• 검사 예외도 아니고 런타임 예외도 아닌 throwable은 정의하지 말아!!
• 검사 예외 경우 복구에 필요한 정보를 알려주는 메서드를 제공하자!

[Irisation23]

오랜만에 강경한 표현이 나오는 부분이였네요.
throwable은 이로울 게 없으니 절대로 사용하지 말라는 Joshua Bloch 님의 명언 잊지 않겠습니다. 👍

[JoisFe]

용어가 한글이라 헷갈릴 수 있어 정리합니다.

용어 정리

크게 나누어

• 예외 : 프로그램 코드에 의해서 수습될 수 있는 다소 미약한 오류
• 에러 : 프로그램 코드에 의해서 수습될 수 없는 심각한 오류

구체적으로

• 검사예외 (Other checked exception subclasses) : 런타임 예외가 아닌 Exception
• 런타임 예외 (Runtime Exception)
• 예외 (Error) : 프로그램 코드에 의해서 수습될 수 없는 심각한 오류

checked vs unchecked

• checked : 컴파일러가 예외 체크
• unchecked : 컴파일러가 예외 체크 x

[corock]

확실하지 않으면 승부를 걸지 마라, 이런거 안 배웠어?

문구가 생각나는 아이템 리뷰였네요~ 잘 봤습니다.

검사 예외(checked exception), 비검사 예외(unchecked exception)는 참... 한국어로 번역해서 내용 파악하기에 어려움이 더 많은 것 같습니다.
사용자가 애플리케이션을 어떤 시나리오로 사용할 지 모든 상황을 가정할 수 없고, 일반적으로 시스템 요구사항도 많기 때문에 예외 처리는 참 중요하다고 보는데요.
앞선 아이템(#157)과 함께 곱씹어봐야 할 중요한 아이템으로 보입니다.