[아이템 74] 메서드가 던지는 모든 예외를 문서화하라. 검사 예외는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 사용하여 정확히 문서화를 합시다. 상위 클래스 하나로 선언하는 일은 삼가는 게 좋습니다. 어떤 예외를 호출하는지 명확하게 알 수 없고, 같은 맥락에서 다른 예외가 발생할 여지가 있을 경우 이러한 것까지 다 삼켜버릴 수 있기 때문입니다. 비검사 예외 같은 경우 메서드 선언에 throws를 넣는 건 권장하지 않습니다. 검사냐 비검사냐에 따라 API 사용자가 할 일이 달라지므로 이 둘은 확실히 구분해두는 것이 좋습니다....
9장 예외
예외를 제대로 활용한다면 프로그램의 가독성, 신뢰성, 유지보수성이 높아지지만, 잘못 사용한다면 반대의 효과만 나타난다. 이번 장에서는 예외를 효과적으로 활용하는 지침을 다룬다.
[아이템 75] 예외 상세 메시지에 실패 관련 정보를 담으라. 스택 트레이스는 예외 객체의 toString 메서드를 호출해 얻는 문자열입니다. toString 메서드에 발생 원인에 대한 정보는 가능한 많을 수록 좋습니다. 물론 장황하지 않고 필요한 정보만 담는 것입니다. 가장 좋은 건 발생한 예외에 관여된 모든 매개변수와 필드의 값을 실패 메세지에 담는 것입니다. 물론 보안관 관련된 정보는 유의해서 다루어야 합니다. ex) IndexOutOfBoundsException의 상세 메세지에는 범위의 최솟값, 최댓값, 범위를 벗어난 인덱스의 값을 담는 것입니다....
[아이템 76] 가능한 한 실패 원자적으로 만들라. 여기서 말하는 실패 원자적이란 호출한 메서드가 실패하더라도 해당 객체는 호출 전 상태로 유지되는 것입니다. 가장 간단한 방법은 불변 객채로 설계하는 것입니다. 가변 객체일 경우 작업 수행 전에 유효성을 검사합는 것입니다. 1 2 3 4 5 6 7 8 public Object pop() { if (size == 0) { throw new EmptyStachException(); } Object result = el[--size]; el[size] = null; // 참조 해제 return result; } 유효성 검사하는 부분이 없어도 ArrayOutOfBoundsException을 던지지만 이는 추상화 수준에 상황에 어울리지 않습니다....