체크 / 언체크 예외란?
체크예외 : 예외를 잡아서 처리하지 않으면 항상 throws에 던지는 예외를 선언해야 한다.
언체크 예외 : 예외를 잡아서 처리하지 않아도 throws를 생략할 수 있다.
대표적으로 이렇게 각각을 구분할 수 있다.
(추가적으로는 둘다 Exception 클래스의 자식이며 그 중 언체크 예외만이 RuntimeException의 자식들이다 라고도 말할 수 있다.)
스프링 프로젝트에서 체크예외를 던질 경우
스프링 프로젝트에서 체크예외를 처리하는 경우는 2가지로 나눌 수 있다.
1. thorws로 처리 할 경우
thorws로 처리를 한다면 한가지 문제가 발생한다. 바로 예외를 의존한다는 점이다.
만약 A서비스 클래스에서 B서비스 클래스를 의존하고 B서비스의 메서드를 사용했다고 가정하자.
그러면 A 서비스의 메서드는 B서비스가 던지는 throws를 받게 된다. 하지만 A서비스는 해당 예외를 처리할 방도가 없기 때문에 그저 thorws를 할 수 밖에 없고, 그렇게 컨트롤러를 통해 클라이언트에게 전달된다.
이때!!! A서비스에서 B서비스의 메서드를 사용하지 않는다면?!!! 예외를 의존하고 있기 때문에 B서비스의 메서드를 사용하고 있는 모든 메서드와 컨트롤러까지 전달된 throws를 지워주어야 한다. 단일책임 원칙을 위반하게 된것이다.
2. 복구 불가능한 예외를 처리 할 경우
사실 이 부분을 이해하려면 체크예외가 왜 생겨났는지를 알아야한다. 간단하게 말하면 예전에는 예외 처리를 강제하여 개발자가 예외처리하는것을 깜빡하지 않도록 하였고, 복구가 가능하다면, 예외를 복구할 수 있도록 try / catch로 예외를 처리할 수 있게 하였다. 하지만, 시간이 흘러 너무 많은 예외클래스가 만들어졌고, 또한 복구가 불가능한 예외가 대부분이게 되었다. 따라서 개발자는 빠르게 오류로그를 남기고 빠르게 인지하는 것이 필요하다.
언체크 예외를 던지자.
그래서 throws를 난발하지 않기위해 체크예외를 try / catch로 처리를 한다. catch부분에 처리할 예외를 커스텀 비즈니스 예외 클래스에 던져서 처리하고 공통 예외처리를 진행한다.
언체크 예외는 예외처리를 강제하지 않기 떄문에 예외를 의존할 필요가 없다. 또한 공통 예외처리 컨트롤러를 통해서 클라이언트에게 깔끔한 예외 응답값을 전달할 수 있게 된다.
내가 시행착오 겪은 예외 처리
프로젝트를 하며 예외처리는 서비스 로직단에서 처리해주는것이 옳은 것이라고 생각했다. 트랜잭션이 작동하는 곳은 서비스 로직이니까 라는 아주 단순한 생각이었다. 하지만 공부를 하면 할 수록 단일 책임의 원칙이 점점 이해되기 시작했다. mything 프로젝트에서는 s3를 통해서 유저의 프로필 사진을 업로드 한다.
이때 MultipartFile의 InputStream 객체를 파라미터 넣어주어야 한다. InputStream은 체크예외를 던져서 이 예외를 서비스로직까지 전달을 하여 예외를 처리했다.
하지만 만약 내가 s3말고 다른 외부 API를 이용한다면 s3클래스 파일만 수정하는것이 아닌 서비스 로직에서도 수정을 해야하기 때문에 단일 책임원칙을 위반하는 것이었다.
따라서 서비스로직에서 의존하고 있던 체크예외를 지우고, s3클래스 안에 있는 업로드 메서드안에서 언체크 예외를 던지게 로직을 수정하였다.
이로써 다른 API를 이용하여 파일업로드를 진행하여도 서비스로직에서는 변경할 점이 없어지게 되었다.
참고 사이트
