hyeoneee's blog

1. SQLExcpetion

JDBC는 모든 Exception을 SQLException 에 하나에 모두 담아버린다. 대부분의 SQLException은 복구가 불가능하다. DAO 밖에서 SQLException을 다룰 수 있는 가능성은 거의 없다. 따라서 필요도 없는 기계적인 throws 선언이 등장하도록 방치하지 말고 가능한 한 빨리 언체크/런타임 예외로 전환해줘야 한다.

2. DataAccessException

런타임 예외이고 DataAccessException 중 가장 루트 class이다.

JdbcTemplate 템플릿과 콜백 안에서 발생하는 모든 SQLException을 런타임 예외인 DataAccessException으로 포장해서 던져준다.

Spring에서 DB 관련 Exception 은 DataAccessException 으로 한번 감싸줘서 알려준다고 보면 된다.

DBMS에 따라서 에러코드가 다를텐데 그래도 코드는 스프링에서 일관적으로 보여주니 일관성이 있어서 좋을 것이다. 

• dbcTemplate은 SQLException을 단지 런타임 예외인 DataAccessException으로 포장하는 것이 아니라 DB의 에러 코드를 DataAccessException 계층구조의 클래스 중 하나로 매핑해준다.JdbcTemplate에서 던지는 예외는 모두 DataAccessException의 서브클래스 타입이다.
• 드라이버나 DB 메타정보를 참고해서 DB 종류를 확인하고 DB별로 미리 준비된 매핑정보를 참고해서 적절한 예외 클래스를 선택하기 때문에 DB가 달라져도 같은 종류의 에러라면 동일한 예외를 받을 수 있는 것이다.

주의할점은, 

키값 중복이 되는 같은 상황이라도 똑같은 예외 발생하지 않을 수 있다.

• 데이터 액세스 기술에 상관없이 키 값이 중복이 되는 상황에 아래와 같이 동일한 예외가 발생하지 않는다.
• JDBC는 DuplicateKeyException, 하이버네이트는 ContraintViolationException을 발생시킬 것이다.

3. 결론

결론적으로, 스프링이 잘 정립한 DataAccessException을 활용하는 것이 바람직 하지만, 특정기술에 따라 예상하지 못한 결과가 나올수 있다. 

아직 모든 예외가 명확하게 추상화되어있지 않다. 

이런 경우 로직에서 적절한 DataAccessException의 하위 클래스로 전환하는 방법 등을 사용해서 최대한 일관된 예외 전략을 가져가는 것이 좋을 것 같다.

스프링은 DataAccessException을 통해 DB에 독립적으로 적용 가능한 추상화된 런타임 예외계층을 제공한다.

DAO를 데이터 액세스 기술에서 독립시키려면 인터페이스 도입과 런타임 예외 전환, 기술에 독립적인 추상화된 예외로 전환이 필요하다.

참고)

https://gunju-ko.github.io/toby-spring/2018/11/07/%EC%98%88%EC%99%B8-%EC%B2%98%EB%A6%AC.html

https://velog.io/@kyle/%ED%86%A0%EB%B9%84-%EC%98%88%EC%99%B8-%EC%B2%98%EB%A6%AC

https://withseungryu.tistory.com/95

https://namocom.tistory.com/913