하위 계층의 예외 처리를 신중하게 하자

어떤 메소드가 자신이 수행하는 작업과 뚜렷한 관계가 없는 예외를 발생시킨다면 혼란스러울 것이다. 이런 일은 저수준의 추상체에서 발생한 예외를 메소드 전파할 때 종종 생긴다. 이것은 혼란스럽기도 하지만, 상위 계층의 API에서 세부적인 구현 내역이 노출된다. 만일 상위 계층의 구현 내역이 차후 배포판에서 변경되면, 거기에서 발생시키는 예외도 변경될 것이고, 그 결과로 기존 클라이언트 프로그램에도 영향을 줄 것이다. 이런 문제를 방지하려면, 상위 계층에서 하위 계층의 예외를 반드시 catch해야 한다. 그리고 그 예외대신에 상위 계층의 추상체가 알 수 있는 예외로 바꿔 던져야 한다. 이와 같은 이디엄을 예외 변환이라고 한다.

//예외 변환

try{

//하위 계층의 추상체를 사용하여 작업하는 코드(DB작업등.)

....

}catch(LowerLevelException ex){

throw new HigherLevelException(...):

}

다음은 List인터페이스의 골격 구현이라고 할 수 있는 Abstract-SequentialList의 예외 변환 코드이다. List<E> 인터페이스의 get메소드를 올바르게 구현하기 위해, API문서의 그 메소드 명세에 나와 있는대로 예외 변환을 한 것이다.

예외를 유발시킨 근원인 저수준 예외가 고수준 예외로 전달되는 것으로써, 이 때 고수준 예외에서는 저수준 예외를 가져오는 접근자 메소드를 제공한다.

//예외 연쇄

try{

...

//저수준의 추상체를 사용하여 작업을 하는 코드

}catch(LowerLevelException cause){

throw new HigherLevelException(cause)

}

//예외 연쇄를 사용하는 고수준 예외 클래스

class HigherLevelException extends Exception{

HigherLevelException(Throwable cause){

super(cause);

}

}

하위 계층(저수준)에서 발생한 예외를 분별없이 전파하는 것보다는 예외 변환을 사용하는 것이 좋지만, 예외 변환 역시 남용해서는 안된다.

요약하면, 하위 계층에서 발생한 예외를 막거나 그 자체에서 처리할 수 없다면, 예외 변환 방법을 사용하자. 예외 연쇄는 모든 경우에서 가장 좋은 방법을 제공한다. 예외 연쇄를 이용하면, 하위 계층의 예외가 발생했을 때 거기에 적합한 상위 계층 예외를 던질 수 있으며, 문제의 근원이 되는 하위 계층 예외 정보를 기록하여 시스템 장애 분석에 사용할 수 있다.

메소드가 던지는 모든 예외를 문서화하자

메소드를 올바르게 사용하려면 그 메소드의 명세가 문서화되어야 하며, 그 메소드가 던지는 예외 또한 상세히 기술되어야 한다.

Javadoc의 @throws 태그를 사용해서 항상 checked 예외는 별도로 선언하고, 각 예외가 발생하는 상황을 정확하게 문서화하자.

Javadoc의 @throws 태그를 사용하여 메소드가 던질 수 있는 unckecked예외를 문서화하자. 그러나 메소드 선언부의 throws 키워드에는 unckecked예외를 넣지 말자.

(주석에는 unckecked 예외를 적고, 메소드 선언 시에는 unckecked메소드를 던지지 않는다

만일 같은 클래스의 여러 메소드에서 동일한 이유로 어떤 한 가지 예외를 던진다. 그 예외를 각 메소드에 개별적으로 문서화하는 것보다는 클래스의 문서화 주석에 그 예외의 설명을 추가하는 것이 좋다.