-
언제 무엇을 사용해야 하는지 알아보자.
- 호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라.
- 검사와 비검사 예외를 구분하는 기본 규칙
- 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아서 처리하거나, 더 바깥으로 전파하도록 강제된다.
- 메서드 선언에 포함된 검사 예외 각각은 그 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려주는 것이다.
- 즉, API 설계자가 사용자에게 검사 예외를 던져주고 그 상황에서 회복해내라고 요구하는 것이다.
- 예외를 잡기만 하고 별다른 조치를 취하지 않을 수 있지만, 이는 그다지 좋지 않는 생각이다. (아이템 77 참고)
- 이 둘은 동작 측면에서는 다르지 않다.
- 이 둘은 프로그램에서 잡을 필요가 없거나 혹은 통상적으로는 잡지 말아야 한다.
- 프로그램에서 비검사 예외나 에러를 던졌다는 것은 복구가 불가능하거나, 더 실행해봐야 득보단 실이 많다는 뜻이다.
- 이러한 throwable 을 잡지 않은 스레드는 적절한 오류 메세지를 내뱉으며 중단된다.
- 개인적으로 헷갈렸던 부분 : 검사 예외는 시스템을 강제 종료하지 않는다. 다만, 컴파일 불가능. 검사 예외는 스레드 혹은 시스템을 강제 종료한다.
- (https://stackoverflow.com/questions/18607912/will-a-java-exception-terminate-the-whole-java-application)
- 프로그래밍 오류를 나타낼 때 사용한다.
- 대부분 전제 조건을 만족하지 못했을 경우 발생한다.
- 전제 조건 위배란 클라이언트가 API 명세에 기록된 제약을 지키지 못한 경우로 볼 수 있다.
- jvm 자원 부족, 불변식 깨짐 등 더 이상 수행을 계속할 수 없는 상황을 나타낼 때 사용한다.(업계에 널리 퍼진 규약)
- Error 클래스를 상속해 하위 클래스를 만드는 일은 하지 않는다.
- 즉, 개발자가 직접 구현하는 비검사 throwable은 모두 RuntimeException 하위 클래스여야 한다.(직접적이든 간접적이든)
- AssertionError 제외하고는 throw 하지도 않는다.
- 복구할 수 있는 상황인지 프로그래밍 오류인지가 항상 명확히 구분되지는 않는단 사실이다.
- 자원 고갈 상황이 복구될 수 있는 것인지는 API 설계자의 판단에 달렸다.
- 복구 가능하다고 믿는다면 검사 예외
- 그렇지 않다면 런타임 예외
- 확신하기 어렵다면 아마도 비검사 예외를 선택
- 자바 언어 명세에 다루지 않지만, 이런 throwable은 암묵적으로 일반적인 검사 예외(Exception의 하위 클래스 중 RuntimeException을 상속하지 않는)처럼 다룬다.
- 써서 좋을 게 없으니 사용하지 않는다.
- throwable은 API 사용자를 헷갈리게 할 뿐이다.
- 예외 역시 어떤 메서드라도 정의할 수 있는 완벽한 객체다.
- 예외의 메서드는 주로 그 예외를 일으킨 상황에 관한 정보를 코드 형태로 전달하는데 쓰인다.
- 이런 메서드가 없다면 오류 메세지를 개발자가 파싱해서 정보를 빼내야 하는데 대단히 나쁜 습관이다.
- throwable 클래스들은 대개 오류 메세지 포맷을 상세히 기술하지 않는데, jvm이나 릴리스에 따라 포맷이 달라질 수 있다는 뜻이다.
- 즉, 메세지 문자열을 파싱해서 얻은 코드는 깨지기 쉽고, 다른 환경에서는 동작하지 않을 수도 있다.
- 검사 예외는 복구할 수 있는 조건일 때 발생하므로, 특히 예외 상황을 벗어나는 데 필요한 정보를 알려주는 메서드를 함께 제공하는 것이 중요하다.(아이템 75 참고)