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

wisdom·2023년 3월 9일
0

Effetctive Java

목록 보기
70/80
post-thumbnail

자바는 문제 상황을 알리는 타입(throwable)으로 검사 예외, 런타임 예외, 에러, 이렇게 세 가지를 제공한다.

언제 어떤 것을 사용해야 할까?

검사 예외

호출하는 쪽에서 복구할 것으로 여겨지는 상황이라면 검사 예외를 사용하자. 이것은 검사와 비검사 예외를 구분하는 기본 규칙이다. 검사 예외를 던지면 호출자가 그 예외를 catch 로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다. 따라서 메서드 선언에 포함된 검사 예외 각각은 그 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주는 것이다.

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

비검사 예외

비검사 throwable은 두 가지로, 런타임 예외에러다. 이 둘은 프로그램에서 잡을 필요가 없거나 통상적으로 잡지 말아야 한다. 이런 throwable을 잡지 않는 스레드는 적절한 오류 메시지를 내뱉으며 중단된다.

프로그래밍 오류를 나타낼 때는 런타임 예외를 사용하자. 런타임 예외의 대부분은 전제조건을 만족하지 못했을 때 발생한다. 전제조건 위배란 단순히 클라이언트가 해당 API의 명세에 기록된 제약을 지키지 못했다는 뜻이다.

에러는 보통 JVM이 자원 부족, 불변식 깨짐 등 더 이상 수행을 계속할 수 없는 상황을 나타낼 때 사용한다. 따라서 Error 클래스를 상속해 하위 클래스를 만드는 일은 자제하기 바란다. 다시 말해, 우리가 구현하는 비검사 throwable은 모두 RuntimeException 의 하위 클래스여야 한다. Error 는 상속하지 말고, throw 문으로 직접 던지는 일도 없어야 한다(단, AssertionError 는 예외다).

throwable

throwable 은 언제 사용하면 좋을까?

throwable은 이로울게 없으니 절대로 사용하지 말자! 정상적인 예외보다 나을 게 하나도 없으면서 API 사용자를 헷갈리게 할 뿐이다.


📌 핵심 정리

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

profile
백엔드 개발자

0개의 댓글