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

Rupee·2022년 12월 10일
0

이펙티브 자바

목록 보기
68/76
post-thumbnail

자바는 문제 상황을 알리는 타입(throwable)으로 다음의 세가지를 제공한다.

  1. 검사 예외 : Exception 하위 클래스들
  2. 런타임 예외 : RuntimeException 하위 클래스들
  3. 에러 : Error 하위 클래스들

해당 세가지 중에 언제 어떠한 타입을 사용하면 좋을지 알아보도록 하자.

☁️ 검사 예외

🔖 검사 예외
호출자는 반드시 그 예외를 catch 로 잡아 처리하거나 throws 를 통해 더 바깥으로 전파하도록 강제해야 한다.

즉 이는 API 설계자가 API 사용자에게 검사 예외를 던져주어, 그 상황에서 회복해내라고 요구한 것이라고 볼 수 있다. (물론 예외를 잡기만 하고 별다른 조치를 취하지 않을 수도 있지만 좋지 않은 방법이다)

따라서 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 사용하자.

☁️ 비검사 예외

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

따라서 만약 프로그램에서 비검사 예외나 에러를 던졌다는 것은, 복구가 불가능하거나 더 실행해봐야 득보다 실이 많다는 뜻을 나타낸다.

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

🌱 런타임 예외

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

대부분이 전제조건을 만족하지 못한 경우, 즉 단순히 클라이언트가 해당 API의 명세에 기록된 제약을 지키지 못했을때 발생한다. 이런 경우는 복구가 가능하지 않으므로 예외 검사를 강제하지 않게 되는 것이다.

예를 들어 배열의 인덱스는 0에서 배열크기-1이어야 하지만, 이게 지켜지지 않는다면 비검사 예외인 ArrayIndexOutOfBoundsException 이 발생하게 된다.

하지만 조건에서 문제가 있는 것이 복구할 수 있는 상황(ex)자원 고갈)인지 프로그래밍 오류(ex)말도 안되는 크기의 배열 할당) 인지 항상 명확이 구분이 되지 않기 때문에, 자원 고갈 상황이 복구 가능하다고 믿는다면 API 설계자의 판단에 따라 검사 예외 그렇지 않다면 런타임 예외를 사용하면 된다.

🌱 에러

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

💡 주의 사항
직접 예외 클래스를 만들때는 Error 클래스를 상속해 하위 클래스를 만들지 말아야 하며, 비검사 throwable 은 모두 RuntimeException 의 하위 클래스어야한다. 더불어 Error는 상속 뿐만 아니라 throw 문으로 직접 던져서도 안된다.(예외 : AssertionError)

☁️ 예외 메서드

예외도 하나의 객체이므로, 어떠한 메서드라도 정의할 수 있다.

주로 그 예외를 일으킨 상황에 대한 정보를 코드 형태로 전달하는데 쓰이는데, 만약 메서드를 정의하지 않는다면 프로그래머들은 오류 메시지를 파싱해 직접 정보를 빼내야 하므로 정의하는 것이 좋다.

특히, 검사 예외는 호출자가 예외 상황에서 벗어나 복구할 수 있도록 필요한 정보를 알려주는 메서드를 함께 제공하는 것이 중요하다.

예를 들어 쇼핑몰에서 물건을 구입하는데 카드 잔고가 부족하여 검사 예외가 발생했다면, 잔고가 얼마나 부족한지 알려주는 접근자 메서드가 필요할 것이다.(아이템 75)

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

이미지 참고 자료
예외 클래스

profile
개인용으로 공부하는 공간입니다. 잘못된 부분은 피드백 부탁드립니다!

0개의 댓글