반응형
1. 체크 예외, 언체크 예외를 언제 쓸 것인가?
- 기본적으로 언체크(런타임) 예외를 사용하자.
- 비즈니스 로직상 해당 예외를 잡아서 반드시 처리해야 하는 문제일 때만 사용
- 복구가 너무 중요할 때 후처리가 필요한 경우에 사용
- ex) 계좌 이체 실패 , 결제시 포인트 부족, 로그인 ID, PW 불일치 등의 예외
- 체크 예외로 만들어 두면, 컴파일러를 통해 실수로 놓친 예외를 인지할 수 있다.
2. 체크 예외의 문제점
1) 복구 불가능한 예외의 경우
- 체크 예외 중에서 SQLException 처럼 데이터베이스에서 발생하는 문제들은 대부분 애플리케이션 로직에서 복구가 불가능해 처리할 방법이 없다.
- 어차피 처리할 방법이 없기에 리포지토리 > 서비스 > 컨트롤러에서 모두 던질 수 밖에 없음
- 해결 할 수도 없는 예외를 계속 던지는 코드가 들어간다.
2) 예외에 의존하는 문제
- 체크 예외 중에서도 특정 기술에 의존하는 예외( SQLException)를 사용하면 변경에 대응하기 어렵다.
- 의존하던 예외가 다른 예외로 바뀌면 서비스, 컨트롤러, 레포지토리등 모든 곳의 코드를 변경해야한다.
- 결과적으로 OCP, DI를 통해 클라이언트 코드의 변경 없이 대상 구현체를 변경할 수 있다는 장점이 발목을 잡게 된다.
3) 안좋은 해결법
- Exception 으로 잡아서 처리하거나 던지는 것을 생각 해 볼 수 있다.
- 코드가 깔끔해지는 것 같지만, Exception 은 최상위 타입이므로 모든 체크 예외를 다 밖으로 던지는 문제가 발생한다.
- 문법에 맞다고 판단해서 컴파일 오류가 발생하지 않아서 다른 체크 예외를 체크할 수 있는 기능이 무효화되고, 중요한 예외를 다 놓치게 된다.
- 이렇게 하면 체크 예외를 의도한 대로 사용하는 것이 아니다.
- 따라서 꼭 필요한 경우가 아니면 이렇게 Exception 자체를 밖으로 던지는 것은 좋지 않은 방법이다
4) 좋은 해결법
- 체크 예외를 RuntimeException 상속 받아 런타임 예외로 변환한다.
- 런타임 예외이기 때문에 처리나 던질 필요가 없이 흘려보낸다.
- 그러면 의존적인 문제도 없고 반복적으로 던지는 코드가 필요없다.
- 체크 예외의 이런 문제점 때문에 대부분 런타임 예외(JPA, 스프링, 각종 라이브러리)를 기본으로 제공한다.
- 추가로 런타임 예외가 명확하고 중요하다면, 던지는 코드를 남겨서 예외를 인지 할 수 있게 해주거나 문서화 한다. 처리가 필요한거면 처리해도 됨.
5) 공통 예외 처리
- 복구 불가능한 예외는 일관성 있게 공통으로 처리하는 부분을 만들어서 처리
- 웹 애플리케이션이라면 서블릿의 필터, 인터셉터, 스프링 ControllerAdvice 에서 공통으로 처리한다.
- 구현 기술이 변경되는 경우, 예외를 공통으로 처리하는 곳에서는 예외에 따른 다른 처리가 필요할 수 있다. 하지만 한곳만 변경하면 되기 때문에 변경의 영향 범위는 최소화 된다
- 해결이 불가능한 공통 예외는 별도의 오류 로그를 남기고, 오류를 빨리 인지할 수 있도록메일, 알림(문자, 슬랙)등을 통해서 전달 받아야 한다.
6) 결론 정리
- 복구가 너무 중요하고 후처리가 필요할때는 체크예외를 쓰고 잡아서 처리한다.
- 그 외에는 모두 런타임 예외로 변경해서 쓰고 공통으로 예외처리한다.
반응형