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

개인룸/도윤

UroJem 2023. 10. 16. 00:33

자바는 문제 상화을 알리는 타입(Throwable)으로 세 가지를 제공한다.

검사예외

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

검사와 비검사 예외를 구분하는 기본 규칙으로 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 상위 객체로 예외를 던지도록 강제한다.

RuntimeException을 빼면 모두 검사 예외(checked exception)들이다.

만드려는 API에 반드시 예외적인 상황이 나올 수 있다면

checked exception을 던져 사용한 클라이언트가 예외적인 상황을 처리하도록 강제한다.

상위로 다시 던지거나 try/catch 하지 않으면 컴파일이 되지 않도록 강제하게 된다.

마땅한 검사 예외가 없다면 Exception을 상속받아 별도의 검사 예외 객체를 만들어 처리할 수 있다.

API 설계자는 API 사용자에게 검사 예외를 던져주어 그 상황에서 회복해내라고 요구한 것이다.

물론 사용자는 예외를 잡기만 하고 별다른 조치를 취하지 않을 수도 있지만, 이는 보통 좋지 않은 생각이다.

두가지로 런타임 예외와 에러다. 검사 예외와 달리 프로그램에서 잡을 필요가 없거나 혹은 통상적으로 잡지 말아야 한다.

프로그램에서 런타임 예외나 에러를 던지면 복구가 불가능하거나 더 실행해봐야 득보다는 실이 많다는 뜻이다.

이런 throwable을 잡지 않은 스레드는 적절한 오류 메시지를 뱉으며 중단된다.

프로그래밍 오류를 나타낼 때는 런타임 예외를 사용하자.

대부분 전제조건을 만족하지 못했을 때 발생하여 예컨대 배열의 인덱스는 0 ~ 배열크기-1 사이여야 한다.

ArrayIndexOutOfBoundsException이 발생 했다면 이 전제조건이 지켜지지 않았다는 뜻이다.

복구할 수 있는 상황인지 프로그램 오류인지 항상 명확히 구분되지 않는데

예를 들어 자원 고갈은 말도 안 되는 크기의 배열을 할당해 생긴 프로그래밍 오류일 수 있고 진짜 자원이 부족해서 발생할 문제일 수 있다.

자원이 일시적으로 부족하여 수요가 순간적으로 몰린 것이라면 충분히 복구할 수 있는 상황일 것이다.

따라서 해당 자원 고갈 상황이 복구될 수 있는 것인지 API 설계자의 판단에 달렸다.

복구가 가능하다고 믿는다면 검사 예외를, 그렇지 않다면 런타임 예외를 사용하자.

확신하기 어렵다면 비검사 예외를 선택하는 편이 났다.

JVM의 자원 부족, 불변식 깨짐 등 더 이상 수행을 계속할 수 없는 상황을 나타낼 때 사용한다.

자바 언어 명세가 요구하는 것은 아니지만 Error 클래스를 상속해 하위 클래스를 만드는 일은 자제하는 것이 업계의 규약이다.

다시 말해 프로그래머가 구현하는 비검사 throwable은 모두 RuntimeException의 하위 클래스여야 한다.

Error는 상속하지 말아야 할 뿐 아니라 throw 문으로 직접 던지는 일도 없어야 한다. (AssertionError는 예외)

Exception, RuntimeException, Error를 상속하지 않는 throwable을 만들 수도 있다.

그런 객체는 암묵적으로 RuntimeException을 상속하지 않은 Exception 하위 클래스(일반 검사예외) 처럼 다루지만

API 사용자를 헷갈리게 하고 정상적인 검사 예외보다 하나도 나은게 없어 이로울게 없으니 절대 사용하면 안된다.

예외 메서드는 주로 그 예외를 일으킨 상황에 관한 정보를 코드 형태로 전달하는데 쓰이는데 이런 메서드가 없다면 호출자들은 오류 메시지를 파싱해 정보를 빼내야 한다.

throwable 클래스들은 대부분 오류 메세지 포맷을 상세히 기술하지 않는데, JVM 릴리즈에 따라 포맷이 달라질 수 있다.

따라서 메세지 문자열을 파싱해 얻은 코드는 깨지기 쉽고 다른 환경에서 동작하지 않을 수 있다.

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

복구할 수 있는 상황이면 검사 예외를, 프로그래밍 오류라면 비검사 예외를 던지자.

확실하지 않다면 비검사 예외를 던지자. 검사 예외도 아니고 런타임 예외도 아닌 throwable은 정의하지도 말자.

검사 예외라면 복구에 필요한 정보를 알려주는 메서드도 제공하자.