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

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

언제 무엇을 사용할지 헷갈리는 프로그래머들이 많기 때문에 참조할 좋은 지침들이 있다.

 

 

1. 검사 예외 (Checked Exception)

• Exception 클래스를 상속받은 예외 타입 중에서 RuntimeException을 제외한 나머지 예외들
• 컴파일러가 검사 예외를 체크하고, 예외를 처리하지 않으면 컴파일 오류가 발생한다.
• I/O 문제, 네트워크 연결 실패 등 프로그램의 외부적인 환경 변화에 따른 문제 상황을 나타내는 데 사용된다.

 

2. 런타임 예외 (Runtime Exception)

• RuntimeException 클래스를 상속받은 예외 타입을 가리킨다.
• 컴파일러가 이 예외를 체크하지 않으며, 예외 처리가 선택 사항이다.
• 배열 인덱스의 범위 초과, NullPointerException, ArithmeticExcetpion 등 실행 시에 발생할 수 있는 프로그래밍 오류나 예측 불가능한 환경 변화에 의한 문제 상황을 나타내는 데 사용된다.
  
  

3. 에러 (Error)

• Error 클래스를 상속받은 예외 타입을 가리킨다.
• 주로 시스템 레벨에서 발생하는 치명적인 문제를 나타낸다.
• 메모리 부족, 스택 오버플로우 등과 같이 프로그램이 복구할 수 없는 치명적인 상황을 나타내는 데 사용된다.

---

 

검사 예외

 

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

 

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

 

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

쇼핑몰에서 물건을 구입하려는데 카드 잔고가 부족하여 검사 예외가 발생 -> 해당 예외는 잔고가 얼마나 부족한지를 알려주는 접근자 메서드를 제공해야 한다.

 

 

파일을 찾지 못했을 때 - 검사 예외

 

 

 

비검사 예외

 

• 비검사 예외인 런타임 예외와 에러는 동작 측면에서 다르지 않다.
• 이 둘은 프로그램에서 잡을 필요가 없거나 혹은 통상적으로는 잡지 말아야 한다.
• 프로그램에서 비검사 예외나 에러를 던졌다는 것은 복구가 불가능하거나 더 실행해봐야 득보다는 실이 많다는 뜻이다.

 

 

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

 

• 런타임 예외의 대부분은 전제조건을 만족하지 못했을 때 발생한다.
• 예를 들어, 배열의 인덱스는 0에서 '배열크기 -1' 사이여야 한다.  ArrayIndexOutOfBoundsException 은 이 전제조건이 지켜지지 않았다는 뜻이다.

 

배열 범위를 벗어났을 때 - 런타임 예외

 

 

복구할 수 있는 상황인지 프로그래밍 오류인지 항상 명확히 구분되지 않을 때

 

• 예를 들어, 자원 고갈은 말도 안되는 크기의 배열을 할당해 생긴 프로그래밍 오류일 수 있고, 진짜로 자원이 부족해서 발생한 문제일 수도 있다.
• API 설계자는 이러한 자원 고갈 상황을 복구 가능하다고 믿는다면 검사 예외를, 그렇지 않다면 런타임 예외를 사용해야 한다.
• 확신하기 어렵다면 비검사 예외를 선택하는 편이 좋다.

 

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

 

• Error 클래스를 상속해 하위 클래스를 만드는 일은 업계에 널리 퍼진 규약이다.
• 우리가 구현하는 비검사 throwable은 모두 RuntimeException의 하위 클래스여야 한다.
• Error는 상속하지 말아야 할 뿐 아니라 throw 문으로 직접 던지는 일도 없어야 한다.(AssertionError는 예외)

 

재귀 호출로 인한 스택 오버플로우 - 에러

 

 

 

결론

 

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