[스프링 DB 1편] - 14. 스프링 예외 처리

 

체크 예외와 인터페이스

 

서비스 계층은 가급적 특정 구현 기술에 의존하지 않고, 순수하게 유지하는 것이 좋다.

 

이렇게 하려면 예외에 대한 의존도 함께 해결해야한다.

예를 들어서 서비스가 처리할 수 없는 SQLException 에 대한 의존을 제거하려면 어떻게 해야할까?

 

서비스가 처리할 수 없으므로 리포지토리가 던지는 SQLException 체크 예외를 런타임 예외로 전환해서 서비스 계층에 던지자.

 

이렇게 하면 서비스 계층이 해당 예외를 무시할 수 있기 때문에,

 

특정 구현 기술에 의존하는 부분을 제거하고 서비스 계층을 순수하게 유지할 수 있다.

 

 

 

체크 예외 코드에 인터페이스 도입

public class MemberRepositoryV3 implements MemberRepositoryEx {
    public Member save(Member member) throws SQLException {
        String sql = "insert into member(member_id, money) values(?, ?)";
    } }

 

인터페이스의 구현체가 체크 예외를 던지려면, 

 

public interface MemberRepositoryEx {
    Member save(Member member) throws SQLException;
    Member findById(String memberId) throws SQLException;
    void update(String memberId, int money) throws SQLException;
    void delete(String memberId) throws SQLException;
}

 

인터페이스 메서드에 먼저 체크 예외를 던지는 부분이 선언 되어 있어야 한다. 

 

그래야 구현 클래스의 메서드도 체크 예외를 던질 수 있다.

 

하지만 이것은 우리가 원하던 순수한 인터페이스가 아니다. (SQLException - JDBC 기술에 종속적인 인터페이스)

 

향후 JDBC가 아닌 다른 기술로 변경한다면 인터페이스 자체를 변경해야 한다.

 

 

인터페이스에 런타임 예외를 따로 선언하지 않아도 되는 런타임 예외를 적용하자 ! 

 

 

 

런타임 예외 적용

 

public class MyDbException extends RuntimeException

 

RuntimeException 을 상속받았다.

 

따라서 MyDbException 은 런타임(언체크) 예외가 된다.

 

 

 MemberRepository 인터페이스 적용 

public class MemberRepositoryV4_1 implements MemberRepository

public Member save(Member member)

 

/**
* 예외 누수 문제 해결
* 체크 예외를 런타임 예외로 변경
* MemberRepository 인터페이스 사용 * throws SQLException 제거
*/

 

catch (SQLException e) {
        throw new MyDbException(e);

기존 체크 예외인 SQLException 을 RuntimeException 을 상속받은 MyDbException 으로 변환

 

기존 예외를 생성자를 통해서 포함하고 있는 것을 확인할 수 있다.

 

그래야 예외를 출력했을 때 원인이 되는 기존 예외도 함께 확인할 수 있다.

 

MyDbException 이 내부에 SQLException 을 포함하고 있다고 이해하면 된다.

 

예외를 출력했을 때 스택 트레이스를 통해 둘다 확인할 수 있다.

 

예외를 변환할 때는 기존 예외를 꼭! 포함하자.

 

 

정리

 

체크 예외를 런타임 예외로 변환하면서 인터페이스와 서비스 계층의 순수성을 유지할 수 있게 되었다.

 

덕분에 향후 JDBC에서 다른 구현 기술로 변경하더라도 서비스 계층의 코드를 변경하지 않고 유지할 수 있다.

 

 

 

데이터 접근 예외 직접 만들기

 

데이터베이스 오류에 따라서 특정 예외는 복구하고 싶을 수 있다.

예를 들어서 회원 가입시 DB에 이미 같은 ID가 있으면 ID 뒤에 숫자를 붙여서 새로운 ID를 만들어야 한다고 가정해보자.

ID를 hello 라고 가입 시도 했는데, 이미 같은 아이디가 있으면 hello12345 와 같이 뒤에 임의의 숫자를 붙여서 가입하는 것이다.

 

 

데이터베이스 오류 코드

데이터를 DB에 저장할 때 같은 ID가 이미 데이터베이스에 저장되어 있다면, 데이터베이스는 오류 코드를 반환하고,

 

이 오류 코드를 받은 JDBC 드라이버는 SQLException 을 던진다.

 

그리고 SQLException 에는 데이터베이스가 제공하는 errorCode 라는 것이 들어있다.

 

SQLException 내부에 들어있는 errorCode 를 활용하면 데이터베이스에서 어떤 문제가 발생했는지 확인할 수 있다.

 

 

예외를 확인해서 복구하는 과정

 

서비스 계층에서는 예외 복구를 위해 키 중복 오류를 확인할 수 있어야 한다.

 

그래야 새로운 ID를 만들어서 다시 저장을 시도할 수 있기 때문이다.

 

이러한 과정이 바로 예외를 확인해서 복구하는 과정이다.

 

리포지토리는 SQLException 을 서비스 계층에 던지고 서비스 계층은 이 예외의 오류 코드를 확인해서

 

키 중복 오류( 23505 )인 경우 새로운 ID를 만들어서 다시 저장하면 된다.

 

 

그런데 SQLException 에 들어있는 오류 코드를 활용하기 위해 SQLException 을 서비스 계층으로 던지게 되면,

 

서비스 계층이 SQLException 이라는 JDBC 기술에 의존하게 되면서, 지금까지 우리가 고민했던 서비스 계층의 순수성이 무너진다.

 

 

 

이 문제를 해결하려면 앞서 배운 것 처럼 리포지토리에서 예외를 변환해서 던지면 된다.

 

 

SQLException -> MyDuplicateKeyException

public class MyDuplicateKeyException extends MyDbException

 

기존에 사용했던 MyDbException(RuntimeException) 을 상속받아서 의미있는 계층을 형성한다.

 

이렇게하면 데이터베이스 관련 예외라는 계층을 만들 수 있다.

그리고 이름도 MyDuplicateKeyException 이라는 이름을 지었다.

 

이 예외는 데이터 중복의 경우에만 던져야 한다.

 

이 예외는 우리가 직접 만든 것이기 때문에, JDBC나 JPA 같은 특정 기술에 종속적이지 않다.

 

따라서 이 예외를 사용하더라도 서비스 계층의 순수성을 유지할 수 있다.

(향후 JDBC에서 다른 기술로 바꾸어도 이 예외는 그대로 유지할 수 있다.)

 

 

 

 

 

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-db-1/dashboard

스프링 DB 1편 - 데이터 접근 핵심 원리 - 인프런 | 강의