예외

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

검사예외는 발생한 문제를 프로그래머가 처리하여 안전성을 높이게끔 해주지만, 과하게 사용하면 오히려 쓰기 불편한 API가 된다. API를 제대로 사용해도 발생 할 수 있는 예외이거나 프로그래머가 의미있는 조치를 위할 수 있는 경우라면 이 정도 부담쯤은 받아들일 수 있을 것이다. 여기에 해당되지 않다면 비검사 예외가 좋다.

 

옵셔널을 반환하는 방법도 생가해볼 가치가 있다.

try-catch문을 사용해야 되면 스트림에서 사용 할 수 없다. Optional반환하는 방법도 고민해볼만 한다.

 

메서드를 2개로 쪼개 비검사 예외로 바꾸는 방식이 있다.

수정 전

try {
    obj.action(args);
} catch (TheCheckedException e) {
    ... // 예외 상황에 대처 한다.
}

수정 후 

if(obj.actionPermitted(args)) {
    obj.action(args);
} else {
    ... // 예외상황을 대처한다.
}

 

표준 예외를 사용하라.

표준 예외를 사용하는 장점

• API가 다른 사람이 익히고 사용하기 쉬워진다.
• 낯선 예외를 사용하지 않게 되어 읽기 쉽게 된다.

 

자주 사용되는 예외들

예외	주요 쓰임
IllegalArgumentException	허용하지 않는 값이 인수로 건네졌을 때
IllegalStateException	객체가 메서드를 수행하기에 적절하지 않은 상태일 때
NullPointerException	null을 허용하지 않는 메서드에 null을 건넸을 때
IndexOutOfBoundsException	허용되지 않는 동시 수정이 발견됐을 때
ConcurrentModificationException	허용하지 않는 동시 수정이 발견됐을 때
UnsupportedOperationException	호출한 메서드를 지원하지 않을 때

Exception, RuntimeException, Throwable, Error는 직접 재사용하지 말자. 안정적 테스트가 힘들다.

 

추상화 수준에 맞는 예외를 던져라.

상위계층에서는 저수준 예외를 잡아 자신의 추상화 수준에 맞는 예외로 바꿔 던져야 한다( `예외 번역`이라 한다. ). 

try {
    ... // 저수준 추상화를 이용한다.
} catch(LowerLevelException e) {
    throw new HigherLevelException(...);
}

 

예외 연쇄

상위 클래스의 생성자에게 건네주어 최종적으로 Throwable생성자까지 건넨다.

class HigherLevelException extends Exception {
    HigherLevelException(Throwable cause) {
        super(cause);
    }
}

 

주의 할 점

• 무턱대고 예외를 전파하는 것보다야 예외 번역이 우수한 방법이지만, 그렇다고 남용해서는 곤란하다.
• 저수준 메서드가 반드시 성공하도록하여 아래 계층에서는 예외가 발생하지 않도록 하는 것이 최선이다.
• java.util.logging에 기록하여추가 조치를 할 수 있게 한다.