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

Throwable

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

 

 

검사 예외 (Checked Exception)

• 호출하는 쪽에서 복구하리라 여겨지는 상황이면 검사 예외를 사용
• 검사 예외를 던지면 호출자가 그 예외를 catch로 처리하거나 더 바깥으로 던지도록 강제하게 된다.
• API 설계자는 API 사용자에게 검사 예외를 던져주어 그 상황에서 회복하라고 요구한 것
• 검사 예외는 Exception의 하위 클래스 중 RunitmeException을 상속하지 않는 것
• 호출자가 예외 상황에서 벗어나는 데 필요한 정보를 알려주는 메서드를 함께 제공하자.

 

 

비검사 예외 (Unchecked Exception)

• 프로그램에서 복구가 불가능하거나 더 실행해봐야 득보다 실이 더 많아 잡을 필요가 없거나 잡지 말아야한다.
• 명시적인 예외 처리를 강제하지 않는다.
• Exception, RuntimeException, Error 을 상속하지 않는 throwable은 만들지 말자 → 혼란 야기
• 뭘 사용할지 모르겠다면 비검사 예외를 사용하는 것이 더 나을 것 [아이템 71]

 

1) 런타임 예외

• 프로그래밍 오류를 나타낼 때는 런타임 예외를 사용 (대부분 전제조건 위배 시)
• 구현하는 비검사 throwable은 모두 RuntimeException 의 하위 클래스여야 함

 

 

2) 에러

• 에러는 자바 언어 명세가 요구하는 것은 아니지만 업계에 널리 퍼진 규약 ex) JVM이 자원 부족, 불변식 깨짐
• 시스템 레벨에서 심각하여 예측하거나 처리할 수 있는 방법이 없음
• Error 클래스를 상속해 하위 클래스를 만들지 말아야 하고 throw 문으로 던지지도 말아라.

 

결론

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