티스토리 뷰
728x90
반응형
필요 없는 검사 예외 사용은 피하라
- 검사 예외(Checked Exception)를 싫어하는 프로그래머가 많지만 제대로 사용한다면 API와 프로그램의 질을 높을 수 있습니다.
개인적으로 싫어하는 유형은 필자처럼 try-catch 블럭으로 인해 혹여나 지저분해지지 않을까? 생각할 수도 있을거 같습니다. - 하지만 검사 예외(Checked Exception)를 잘 사용한다면 발생한 문제를 프로그래머가 처리하여 안전성을 높일 수 있습니다.
💡예시
- 아래 예제 코드에서는 CheckedException을 발생시키는 메서드를 호출하여 main 메서드에서 try-catch하거나 혹은 throws를 사용하여 상위 호출자로 던져야 합니다.
public static void main(String[] args) {
ThrowCheckedException("홍길동");
}
public static void ThrowCheckedException(String name) throws Exception {
if (Objects.nonNull(name)) {
throw new Exception("name is not null");
}
}
💡Stream과 Checked Exception
- 검사 예외(Checked Exception)를 던지는 메서드는 스트림 안에서 직접 사용할 수 없습니다.
💡의미있는 처리를 할 수 있다면 비검사 예외를 사용합시다
- API를 제대로 사용해도 발생할 수 있는 예외이거나, 프로그래머가 의미 있는 조치를 취할 수 있는 경우라면 이정도의 부담은 프로그래머가 받아들여도 좋을 검사 예외(Checked Exception)입니다. 하지만 둘 중 어디에도 해당하지 않는다면 비 검사 예외를 사용하는게 좋습니다.
💡하나의 검사 예외만을 던질 경우 고민해볼 필요가 있습니다.
- 아래 메서드에서 두개의 검사 예외를 던지고 있다고 가정을 해보겠습니다. 만약 여기서 새로운 예외가 추가된다 하더라도 catch문에서 하나의 예외 종류만 추가를 해준다면 별 다른 특이사항이 없을 것입니다. 하지만 그게 아니라 예외가 단 한가지라면 try-catch 블럭을 추가하거나 throws를 해야하는데 생각보다 까다로운 상황이 발생할 수 있습니다. 이런 경우 책에서는 검사 예외를 회피하기 위해 적절한 결과 타입을 담은 옵셔널을 반환하는 방벙을 제시하고 있습니다. 하지만 이 방법을 사용하게 되면 예외가 발생했을 경우 호출자에게 적절한 정보를 제공하기 힘들다는 점이 있습니다. 또 다른 방법으로는 검사 예외를 던지는 메서드를 2개로 쪼개 비 검사 예외로 바꾸는 방법이 있습니다.
💡하나의 검사 예외를 2개로 쪼개 비검사 예외로 바꾸는 방식
- 하지만 이 방식에는 단점이 존재합니다. 첫번째로는 모든 상황에서 적용이 불가능합니다. 두번째는 외부 동기화 없는 멀티 쓰레드환경에서 obj.actionPermitted(args) 메서드 호출과 obj.action(args) 메서드 호출 시간 사이에 외부 요인에 의해 상태가 변경이 된다면 문제가 발생할 수 있습니다. 즉 Thread-Safe하지 않습니다.
//before
try {
obj.action(args);
} catch (CheckedException e) {
//logics...
}
//after
if(obj.actionPermitted(args)) {
obj.action(args);
} else {
//logics...
}
✔️ 정리
- 꼭 필요한 곳에서의 검사 예외는 프로그램의 안전성을 높혀줍니다.
- API 호출자가 예외 복구를 할 수 없는 상황이라면 비검사 예외를 사용하는게 좋습니다.
- API 호출자가 예외 복구를 할 수 있고, 해주길 바란다면 옵셔널을 반환할 수 있을지 고민해보는게 좋습니다. 다만 옵셔널로 해결이 되지 않는 경우에는 검사 예외를 던지는게 좋습니다.
참고자료)
https://catsbi.oopy.io/a18e12e1-19f9-46cf-8168-f8d5dc41c223
728x90
반응형
'스터디 > 이펙티브 자바' 카테고리의 다른 글
이펙티브 자바 - Item73. 메서드가 던지는 모든 예외를 문서화하라 (0) | 2022.08.20 |
---|---|
이펙티브 자바 - Item72. 표준 예외를 사용하라 (1) | 2022.08.20 |
이펙티브 자바 - Item70. 복구할 수 있는 상황에는 검사예외를, 프로그래밍 오류에는 런타임 예외를 사용하라 (0) | 2022.08.19 |
이펙티브 자바 - Item69. 예외는 진짜 예외 상황에만 사용하라 (0) | 2022.08.18 |
이펙티브 자바 - Item66. 네이티브 메서드는 신중히 사용하라 (0) | 2022.08.16 |
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
TAG
- spring boot redisson sorted set
- 자바 백엔드 개발자 추천 도서
- service based architecture
- @ControllerAdvice
- 트랜잭셔널 아웃박스 패턴 스프링 부트 예제
- microkernel architecture
- spring boot redisson 분산락 구현
- spring boot excel download oom
- spring boot poi excel download
- spring boot redisson destributed lock
- pipe and filter architecture
- 공간 기반 아키텍처
- space based architecture
- 트랜잭셔널 아웃박스 패턴 스프링부트
- pipeline architecture
- transactional outbox pattern spring boot
- java ThreadLocal
- spring boot excel download paging
- redis sorted set
- 람다 표현식
- transactional outbox pattern
- java userThread와 DaemonThread
- 서비스 기반 아키텍처
- JDK Dynamic Proxy와 CGLIB의 차이
- redis 대기열 구현
- 레이어드 아키텍처란
- redis sorted set으로 대기열 구현
- polling publisher spring boot
- spring boot redis 대기열 구현
- spring boot 엑셀 다운로드
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
글 보관함