예외처리 방법
1. 예외 복구
=> 정상 상태로 돌려 놓는 것. 예외로 인해 기본 작업 흐름이 불가능하다면 다른 작업 흐름으로 자연스럽게 유도해주는 것
ex) SQLException (네트워크가 불안해서 발생하는 문제라면)
1 2 3 4 5 6 7 8 9 10 11 12 | int maxRetry = MAX_RETRY; while(maxEntry --> 0){ try{ .. return; // 작업 성공 }catch(SomeException e){ // 로그 출력 및 정해진 시간만큼 대기 }finally{ // 리소스 반납 } } throw new RetryFailedException(); // 최대 횟수를 넘기면 직접 예외 발생 | cs |
2. 예외처리 회피
예외처리를 담당하지 않고, 호출한 쪽으로 예외를 던져버리는 것.
하지만 무책임한 회피는 금지.
DAO가 SQLException을 생각 없이 던져버리면, 비즈니스 계층이나 웹 컨트롤러에서 SQLException을 제대로 처리할 수 있을지 생각해야 한다.
예외를 회파하는 것은 예외를 복구하는 것처럼 의도가 분명해야 한다.
3.예외전환
발생한 예외를 그대로 넘기는 게 아니라 적절한 예외르 전환해서 던진다.
예외전환을 하는 이유
1. 내부에서 발생한 예외를 그대로 던지는 것이 그 예외 상황에 대한 적절한 의미를 부여해주지 못하는 경우, 의미를 분명하게 해줄 수 있는 예외로 바꿔주기 위해서 사용
2. 예외를 처리하기 쉽고 단순하게 만들기 위해 포장(wrap)하는 것. 주로 예외처리를 강제하는 체크 예외를 언체크 예외인 런타임 예외로 바꾸는 경우 사용
1 2 3 4 5 6 7 8 9 10 | try{ Apartment apart = ApartmentFactory.getInstance().getApartment(); String detailAddress = apart.getDetailAddress(Strig name); }catch(NamingException e){ throw new ApartmentException(e); }catch(SQLException e){ throw new ApartmentException(e); }catch(IOException e){ throw new ApartmentException(e); } | cs |
예외처리 전략
런타임 예외의 보편화
예전에는 복구할 가능성이 조금이라도 있다면 체크 예외로 만든다고 생각했는데, 지금은 항상 복구할 수 있는 예외가 아니라면 일단 언체크 예외로 만드는 경향이 있다. 언체크 예외라도 필요하면 얼마든지 catch블록으로 잡아서 복구하거나 처리할 수 있다. 하지만 대개는 복구 불가능한 상황이고 보나마나 RuntimeException등으로 포장해서 던져야 할 테니 아예 API차원에서 런타임 예외를 던지도록 만드는 것
ex)
SQLException => 언체크/런타임 예외로 전환
JdbcTemplate이 던지는 DataAccessException은 런타임 예외로 SQLException을 포장해주는 역할을 한다.
그래서 복구가 불가능한 예외인 SQLException에 대해 애플리케이션에서는 신경쓰지 않도록 해주는 것이다.
또한 DataAccessException은 SQLEXception에 담긴 다루기 힘든 상세한 예외정보를 의미 있고 일관성 있는 예외로 전환해서 추상화해주려는 용도로 쓰이기도 한다.
(DB에러 코드 매핑을 통한 전환)
(출처 : 토비의 스프링)
'프로그래밍 노트 > JAVA' 카테고리의 다른 글
[JAVA] final 필드와 상수, final 클래스와 final 메소드 (0) | 2018.11.26 |
---|---|
[JAVA] 정적멤버와 static (0) | 2018.11.26 |
[JAVA] 예외처리 - 에러 및 예외종류 (0) | 2018.09.19 |
[JAVA] 컬렉션프레임워크(CollectionFramework) 6 - TreeMap (0) | 2018.09.13 |
[JAVA] 컬렉션프레임워크(CollectionFramework) 5 - HashMap (0) | 2018.09.13 |