반응형
점검지점 예외 (checked error) 은 프로그래머에게 예외상황을 처리하도록 강제함으로써 안전성을 키울수있다.
하지만 모든것이 넘치면 부족하니 못한것처럼 점점지점 예외도 너무 남발하면 사용하기 불편한 API가 될수있다.
다음과 같은 경우를 예를 들어보자
1 2 3 4 5 | try { obj.action(args); catch (Exception e) { .... } | cs |
만약 위에 코드에서 예외가 발생되지 않도록 미리 체크하는 부분이 있으면 굳이 점검지점예외를 사용하지 않아도된다.
1 2 3 4 5 | if (obj.check(args)) { obj.action(args); } else { ... } | cs |
이렇게 리팩터링을 사용하면 좀더 유연하게 사용가능한 API가 될 것이다.
하지만 이런경우처럼 리팩터링을 진행할 수 없는 경우가 있다.
- 만약 위에 코드에서 check를 진행하는 부분에 값이 외부에서 변경되어서 action을 실행하는 시점에는 바뀌어 버리면 예외가 발생할 수 있다.
- check(args)에서 사용하는 메서드 내용이 action()메서드에서 사용하는 내용과 중복되는 경우가 많으면 차라리 점검지점 예외를 사용하는것이 낫다.
출처 : 조슈아 블로크, 『 Effective Java 2/E』, 이병준 옮김, 인사이트(2014.9.1), 규칙59 인용.
반응형
'JAVA > Effective Java' 카테고리의 다른 글
규칙 61 - 추상화 수준에 맞는 예외를 던져라 (0) | 2018.06.01 |
---|---|
규칙 60 - 표준 예외를 사용해라 (0) | 2018.05.29 |
규칙 58 복구가능 상태에는 점검지정 예외를 사용하고, 프로그래밍 오류에는 실행시점 예외를 이용하라. (0) | 2018.05.29 |
규칙 57 예외는 예외적 상황에만 사용하라. (0) | 2018.05.29 |
규칙 56 - 일반적으로 통용되는 작명 관습을 따르라 (0) | 2018.05.29 |