이전

자바 예외처리

처음 자바를 설계할 당시에는 체크 예외가 더 나은 선택이라 생각했다. 그래서 자바가 기본으로 제공하는 기능들에는 체크 예외가 많다. 그런데 시간이 흐르면서 복구 할 수 없는 예외가 너무 많아졌다. 특히 라이브러리를 점점 더 많이 사용하면서 처리해야 하는 예외도 더 늘어났다. 체크 예외는 해당 라이브러리들이 제공하는 모든 예외를 처리할 수 없을 때마다 throws 에 예외를 덕지덕지 붙어야 했다. 그래서 개발자들은 throws Exception 이라는 극단적?인 방법도 자주 사용하게 되었다. 물론 이 방법은 사용하면 안된다. 모든 예외를 던진다고 선언하는 것인데, 결과적으로 어떤 예외를 잡고 어떤 예외를 던지는지 알 수 없기 때문이다. 체크 예외를 사용한다면 잡을 건 잡고 던질 예외는 명확하게 던지도록 선언해야 한다. 체크 예외의 이런 문제점 때문에 최근 라이브러리들은 대부분 런타임 예외를 기본으로 제공한다. JPA 기술도 런타임 예외를 사용한다. 또한 스프링도 대부분 런타임 예외를 제공한다. 런타임 예외도 필요하면 잡을 수 있기 때문에 필요한 경우에는 잡아서 처리하고, 그렇지 않으면 자연스럽게 던지도록 둔다. 그리고 예외를 공통으로 처리하는 부분을 앞에 만들어서 처리하면 된다.

스프링에서 때로는 의미 있는 DAO 가 던지는 예외를 잡아서 비즈니스 로직에 적용하는 경우가 있다. 중복키 예외나 낙관적인 락킹 등이 대표적인 예다. 그런데 이런 의미 있는 예외를 처리하려고 할 때 JDBC 나 각 데이터 액세스 기술에서 던져주는 예외에 일관성이 없기 때문에 구현 기술에 따라 달라지는 예외를 서비스 계층에서 알고 있어야만 한다는 문제가 발생한다. 이 때문에 스프링은 특정 기술이나 DB의 종류에 상관없이 일관된 의미를 갖는 데이터 예외 추상화를 제공하고, 각 기술과 DB 에서 발생하는 예외를 스프링 데이터 예외로 변환해주는 변환 서비스를 제공한다.