Effective java 3/E - 예외 (item 69~77)

Item 69. 예외는 진짜 예외 상황에만 사용하라

예외처리가 성능이 좋을 거란 기대는 하지 말자!

---> 예외는 정말 예외처리가 필요한 경우에만 사용할 것 (일반적인 제어용으로 사용하지 말 것)

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

??

Item 71. 필요 없는 검사 예외 사용은 피하라

검사 예외를 던지는 대신 옵셔널을 반환하자

옵셔널로 충분한 처리가 힘든 경우에 검사 예외를 던지자

==> API 활용이 쉬워진다.

Item 72. 표준 예외를 사용하라

IllegalArgumentException 허용하지 않는 값이 인수로 건네졌을 때

IlegalStateException 객체가 메서드를 수행하기에 적절하지 않은 상태일 때

NullPointerException null을 허용하지 않는 메서드에 null을 건넸을 때

IndexOutOfBoundsException 인덱스가 범위를 넘어섰을 때

ConcurrentModificationException 허용하지 않는 동시 수정이 발견됬을 때

UnsupportedOperationException 호출한 메서드를 지원하지 않을 때

Item 73. 추상화 수준에 맞는 예외를 던지라

수준에 맞는 예외를 던질 것

예외 번역할 때, 예외 연쇄 사용하면 좋음

* 예외 연쇄 (exception chaining) --> 문제의 근본 원인인 저수준 예외를 고수준 예외에 실어 보내는 것

아래 계층에서는 예외가 발생하지 않는 것이 좋음

(아래 계층이란? 메서드의 시작점이라 생각하면 될까? )

Item 74. 메서드가 던지는 모든 예외를 문서화하라

@throws 태그를 사용하여 정확히 문서화 할 것

비검사 목록은 넣지 않아도 됨

Item 75. 예외의 상세 메시지에 실패 관련 정보를 담으라

예외 실패에 관련한 모든 자료를 담는게 좋음 (단, 보안 관련된 내용은 지양할 것)

예외 상세 메시지 != 예외 오류 메시지

가독성보다는 담긴 내용이 중요하다.

예외는 실패와 관련된 정보를 얻을 수 있는 접근자 메서드(setter)를 제공하는게 좋음

Item 76. 가능한 한 실패 원자적으로 만들라

실패 원자적 (failure-atomic)

호출된 메서드가 실패하더라도 해당 객체는 메서드 호출 전 상태를 유지해야 함

- 불변 객체 선언

- 객체의 상태를 바꾸는 코드보다 앞에서 예외를 던짐

- 객체 복사본을 만들어서 사용하는 것

- 실패시 복구를 실행하는 코드를 작성하는 것

Item 77. 예외를 무시하지 말라

catch 안에 어지간하면 작성하고

만약 안한다면 왜 빈 블록을 만드는지 주석을 달 것

그리고 Exception 변수 이름을 ignored로 변경