아이템 69 - 예외는 진짜 예외 상황에만 사용하라
- 예외는 예외 상황에 쓸 목적이므로 JVM에서 그렇게 빠르게 처리해주지 않음
- 예외를 흐름 제어용으로 사용하지 말자
- API는 클라이언트가 정상 제어 흐름에서 예외를 사용할 일이 없어야함
아이템 70 - 복구할 수 있는 상황에는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라
- 문제 상황 : 검사 예외, 런타입 예외, 에러
- 검사 예외는 호출하는 쪽에서 복구하리라 여겨지는 상황에 사용 → 복구 가능
- 런타임 예외는 프로그래밍 오류를 나타낼 때 사용 → 복구 불가능
- 우리가 구현하는 비검사 throwable은 모두 RuntimeException의 하위 클래스여야함
- Error 클래스를 상속해 하위 클래스를 만들지 말자
- 확실하지 않으면 그냥 비검사 예외라고 보자
- 검사 예외라면 복구에 필요한 정보를 알려주는 메서드도 작성
아이템 71 - 필요 없는 검사 예외 사용은 피하라
- 검사 예외를 던지는 메서드는 스트림 안에서 직접 사용 불가
- 만약 꼭 던져야겠다면, 빈 옵셔널을 던지는 방식을 생각해보자
- 옵셔널로도 충분한 정보를 제공하지 못할 경우에만 검사 예외를 던지자.
아이템 72 - 표준 예외를 사용하라
- 예외는 직렬화할 수 있음 → 많은 부담을 줌
- IllegalArgumentException : 허용하지 않는 값이 매개변수로 왔을 때 (null인 경우는 따로)
- IllegalStateException : 객체가 메서드를 수행하기 적절하지 않은 상태 → 초기화되지 않은 객체 사용
- NullPointerException : null 허용하지 않는 메서드에 null 건넸을 때
- Exception, RuntimeException, Throwable, Error는 직접 재사용하지 말자.
아이템 73 - 추상화 수준에 맞는 예외를 던지라
- 저수준 예외를 그대로 상위에 노출하는 것보다는 예외가 발생했을 때 상위 계층에 맞게 번역한 예외를 던지는 것 (예외 번역)이 좋다.
- 남용은 금물
- 가능한한 저수준 메서드가 반드시 성공하도록 → 아래 계층에서 예외 발생 안하도록
아이템 74 - 메서드가 던지는 모든 예외를 문서화하라
아이템 75 - 예외의 상세 메시지에 실패 관련 정보를 담으라
- 예외와 관련된 모든 매개변수, 필드의 값을 실패 메시지에 담는다
- 검사 예외, 비검사 예외 구분 없이 메시지를 담자
아이템 76 - 가능한 한 실패 원자적으로 만들라
- 호출된 메서드가 예외 발생 시, 해당 객체는 메서드 호출 전 상태를 유지해야 한다.
- 불변 객체의 경우는 거의 걱정이 없다.
- 가변 객체의 경우
- 작업 수행에 앞서 매개변수의 유효성을 검사함으로써 가능
- 실패 가능성이 있는 코드를 객체 상태 바꾸는 코드보다 앞에 배치하는 방식
- 객체의 임시 복사본에서 작업 수행한 후, 모두 성공할 때에 원래 객체와 교체하는 방식
- 하지만 너무 복구 비용이 크다면 실패 원자적으로 만들지 못할 수도 있다.
아이템 77 - 예외를 무시하지 말라
- 빈 catch 블록으로 놓지 말자
- 만약 그렇게 놓고 싶으면 그 이유를 주석으로 남기고, 예외 변수의 이름도 ignore로 놓자.
https://product.kyobobook.co.kr/detail/S000001033066