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

0. 요약

자바에서는 문제 상황을 알리는 타입(throwable)으로 검사 예외, 런타임 예외, 에러 를 제공한다. 각각 어떤 상황에 사용해야하는지는 다음과 같다.

• 검사 예외 → 복구할 수 있는 상황, 자원 고갈 상황 복구 가능
• 비검사 예외 → 프로그래밍 오류, 자원 고갈 상황 복구 불가능
• 만약 복구여부를 확실하게 알 수 없다면 비검사 예외를 던지자

 

1. 검사 예외를 사용해야하는 상황

만약 호출하는 쪽에서 복구할 수 있는 상황이라고 여겨지면 검사 예외를 사용하는 것이 좋다.

• 검사 예외 메서드를 사용하면 사용자 측에서 예외 처리 방법
  • catch로 잡아서 처리하기
  • 더 바깥으로 전파하도록 강제하기
• 그 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API사용자에게 알려주고, 해결하라고 요구

 

2. 런타임 예외 vs 에러

둘 다 비검사 throwable에 해당하고, 동작방식은 다음과 같다.

1. 프로그램에서 잡을 필요가 없는 경우
2. 통상적으로 잡지 말아야하는 경우

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

 

3. 비검사 예외(런타임 예외)를 사용해야하는 상황

프로그래밍 오류를 나타낼 때는 비검사 예외를 사용하자. 런타임 예외의 대부분은 전제조건을 위배했을 때 발생하기 때문에 복구할 필요가 없다.

검사 예외 vs 비검사 예외

Q: 만약 복구할 수 있는 상황인지 아닌지 판단하기 애매하다면 어떻게 해야할까?

A : 보통 복구할 수 있는 상황 여부를 판단하기가 어려울 수 있다. 예를 들어 자원 고갈 문제가 매우 큰 배열을 할당해 생긴 프로그래밍 오류일 수도 있고, 진짜로 자원이 부족해서 발생한 문제일 수도 있다. 따라서 API 설계자가 상황을 판단해 복구 가능하다면 검사 예외를, 그렇지 않다면 런타임 예외를 사용하는 것이 좋다. 확신하기 어렵다면 비검사 예외를 선택하는 편이 낫다.

 

4. 에러를 사용해야하는 상황

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

• 되도록이면 하지 말아야 할 것들
  • Error 클래스를 상속한 하위 클래스 생성은 하지 말자
  • Error를 throw 문으로 직접 던지는 것도 하지 말자

 

5. 커스텀 throwable은 정의하지도 말자

Exception, RuntimeException, Error를 상속하지 않는 throwable을 만들 수 있기는 하지만, 만들지 말자.

• 이유
  • 정상적인 검사 예외보다 나을게 하나도 없다
  • API 사용자만 헷갈리게 할 뿐이다

예외의 메서드

예외의 메서드는 주로 그 예외를 일으킨 상황에 관한 정보를 코드 형태로 전달하는데 쓰인다.

이런 메서드가 없다면 프로그래머들은 오류 메시지를 파싱해 정보를 가져와야 하는데, 이 방식에는 다음과 같은 문제점이 있다.

• 포맷이 버전별로 다를 수 있기에 데이터가 쉽게 깨지기 쉽다
• 특정 환경에서의 의존도가 높으므로 다른 환경에서 동작하지 않을 가능성이 높다