[스프링 DB 1편] #6. 스프링과 문제 해결 - 예외 처리, 반복 - (1)

[newh08]

체크 예외와 인터페이스

예외 처리에 대한 부분을 스프링이 어떻게 깔끔하게 해결하는지 + 반복코드 어떻게 간단히 하는지 알아보자.

서비스 계층은 특정 기술에 의존하지 않고 순수하게 유지해야함.
이렇게 하려면 예외에 대한 의존도 해결해야함.

지금까지 여러 노력을 통해 서비스 계층에서 트랜잭션 코드를 없앴음.
지금 남은 SQLException 던지는걸 해결해야함.
서비스가 처리할 수 없으므로 리포지토리가 던지는 SQLException 체크 예외를 런타임 예외로 전환해서 서비스 계 층에 던지자. 이렇게 하면 서비스 계층이 해당 예외를 무시할 수 있기 때문에, 특정 구현 기술에 의존하는 부분을 제거하 고 서비스 계층을 순수하게 유지할 수 있다.

이를 코드로 적용해보자.

먼저 MemberRepository 인터페이스를 도입해 구현 기술을 쉽게 변경할 수 있게 해보자.

지금은 서비스가 특정 리포지토리에 의존하고 있어서 구현 기술을 갈아끼기가 쉽지 않음.
리포지토리에 인터페이스를 도입하면, DI 를 통해 구현 기술을 갈아 끼울 수 있음.

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

특정 기술에 종속되지 않는 순수한 인터페이스이다. 이 인터페이스를 기반으로 특정 기술을 사용하는 구현체를 만들면 된다.

체크 예외와 인터페이스
기존에 이렇게 인터페이스를 도입하지 않은 이유가 있음. 문제가 하나 있기 때문.
왜냐하면 SQLException 이 체크 예외이기 때문이다. 여기서 체크 예외가 또 발목을 잡는다.
체크 예외를 사용하려면 인터페이스에도 해당 체크 예외가 선언 되어 있어야 한다.
예를 들면 다음과 같은 코드가 된다.

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;
}

인터페이스에 throws SQLException 가 있음.
인터페이스가 이미 특정 기술에 종속적이 되어버림.

즉 MemberRepositoryV3 가 throws SQLException 를 하려면 MemberRepositoryEx 인터페이스에도 throws SQLException 이 필요하다.
참고로 구현 클래스의 메서드에 선언할 수 있는 예외는 부모 타입에서 던진 예외와 같거나 하위 타입이어야 한다.
- 예를 들어서 인터페이스 메서드에 throws Exception 를 선언하면, 구현 클래스 메서드에 throws SQLException 는 가능하다. SQLException 은 Exception 의 하위 타입이기 때문이다.

결과적으로 특정 기술에 종속적인 인터페이스를 만들 수 밖에 없음.
인터페이스를 만드는 목적은 구현체를 쉽게 변경하기 위함 인데, 이미 인터페이스가 특정 구현 기술에 오염이 되어 버렸다. 향후 JDBC가 아닌 다른 기술로 변경한다면 인터페이 스 자체를 변경해야 한다.

런타임 예외와 인터페이스
런타임 예외는 이런 부분에서 자유롭다. 인터페이스에 런타임 예외를 따로 선언하지 않아도 된다. 따라서 인터페이스가 특정 기술에 종속적일 필요가 없다.

런타임 예외 적용

실제 코드에 런타임 예외 적용하기.

/**
 * 예외 누수 문제 해결
 * 체크 예외를 런타임 예외로 변경
 * MemberRepository 인터페이스 사용
 */
@Slf4j
public class MemberRepositoryV4_1 implements MemberRepository{

    private final DataSource dataSource;

    public MemberRepositoryV4_1(DataSource dataSource) {
        this.dataSource = dataSource;
    }

    @Override
    public Member save(Member member) {
        String sql = "insert into member(member_id, money) values(?, ?)";

        Connection con = null; // 커넥션이 있어야 연결 가능
        PreparedStatement pstmt = null; // 이걸 가지고 DB 에 쿼리를 날림.

        try {
            con = getConnection();
            pstmt = con.prepareStatement(sql);
            // 위의 sql 에서 파라미터 바인딩 하듯
            pstmt.setString(1, member.getMemberId());
            pstmt.setInt(2, member.getMoney());
            // 실행
            pstmt.executeUpdate();
            return member;
        } catch (SQLException e) {
            throw new MyDbException(e);
        }finally {
            // 시작의 역순으로 close 해야함. connection 을 안닫아주면 계속 열린체로 유지될 수 도.
            close(con, pstmt, null);
        }
    }

    public Member findById(String memberId) {
        String sql = "select * from Member where member_id = ?";

        Connection con = null;
        PreparedStatement pstmt = null;
        ResultSet rs = null;

        try {
            con = getConnection();
            pstmt = con.prepareStatement(sql);
            pstmt.setString(1, memberId);

            // 쿼리의 결과를 ResultSet 으로 반환함.
            rs = pstmt.executeQuery();
            // rs 에서 값을 꺼내야함.
            if (rs.next()) {
                Member member = new Member();
                member.setMemberId(rs.getString("member_id"));
                member.setMoney(rs.getInt("money"));
                return member;
            } else {
                // 오류 메시지는 구체적으로 적는게 나중에 편하다.
                throw new NoSuchElementException("member not found memberId =" + memberId);
            }

        } catch (SQLException e) {
            throw new MyDbException(e);
        } finally {
            close(con, pstmt, rs);
        }
    }

    public void update(String memberId, int money) {
        String sql = "update member set money=? where member_id=?";

        Connection con = null;
        PreparedStatement pstmt = null;

        try {
            con = getConnection();
            pstmt = con.prepareStatement(sql);
            pstmt.setInt(1, money);
            pstmt.setString(2,memberId);
            int resultSize = pstmt.executeUpdate();
            log.info("resultSize={}", resultSize);
        } catch (SQLException e) {
            throw new MyDbException(e);
        }finally {
            close(con, pstmt, null);
        }
    }
    public void delete(String memberId)  {
        String sql = "delete from member where member_id = ?";

        Connection con = null;
        PreparedStatement pstmt = null;

        try {
            con = getConnection();
            pstmt = con.prepareStatement(sql);
            pstmt.setString(1,memberId);
            int resultSize = pstmt.executeUpdate();
            log.info("resultSize={}", resultSize);
        } catch (SQLException e) {
            throw new MyDbException(e);
        }finally {
            close(con, pstmt, null);
        }
    }

    private void close(Connection con, Statement stmt, ResultSet rs) {
        // 더 잘 짜야진 close 코드
        JdbcUtils.closeResultSet(rs);
        JdbcUtils.closeStatement(stmt);
        // 주의! 트랜잭션 동기화를 사용하려면 DataSourceUtils 를 사용해야함.
        DataSourceUtils.releaseConnection(con, dataSource);
        //JdbcUtils.closeConnection(con);
    }

    private Connection getConnection() throws SQLException {
        // 트랜잭션 동기화를 사용하려면 DataSourceUtils 를 사용해야 함.
        Connection con = DataSourceUtils.getConnection(dataSource);
        log.info("get connection = {}, class = {}", con, con.getClass());
        return con;
    }
}

• MemberRepository 인터페이스 구현.
• SQLException 체크 예외를 MyDbException 런타임 예외로 변환해 던짐

예외 변환 - 기존 예외 무시

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

• 잘 보면 기존 예외를 생성자를 통해서 포함하고 있는 것을 확인할 수 있다. 예외는 원인이 되는 예외를 내부에 포 함할 수 있는데, 꼭 이렇게 작성해야 한다. 그래야 예외를 출력했을 때 원인이 되는 기존 예외도 함께 확인할 수 있다.

이번엔 서비스에서 인터페이스를 사용하도록 변경

/**
 * 예외 누수 문제 해결
 */
@Slf4j
public class MemberServiceV4 {

    private final MemberRepository memberRepository;

    public MemberServiceV4( MemberRepository memberRepositoryV3) {
        this.memberRepository = memberRepositoryV3;
    }

    @Transactional
    public void accountTransfer(String fromId, String toId, int money) {
        bizLogic(fromId, toId, money);
    }


    private void bizLogic(String fromId, String toId, int money) {
        // 비즈니스 로직
        Member fromMember = memberRepository.findById(fromId);
        Member toMember = memberRepository.findById(toId);
        memberRepository.update(fromId, fromMember.getMoney() - money);
        // 예외 발생
        validation(toMember);
        memberRepository.update(toId, toMember.getMoney() + money);
    }

    private static void validation(Member toMember) {
        if (toMember.getMemberId().equals("ex")) {
            throw new IllegalStateException("이체중 예외 발생");
        }
    }
}

• MemberRepository 인터페이스 의존
• SQLException 삭제

테스트 코드

@SpringBootTest
@Slf4j
class MemberServiceV4Test {
    public static final String MEMBER_A = "memberA";
    public static final String MEMBER_B = "memberB";
    public static final String MEMBER_C = "ex";

    @Autowired
    private MemberRepository memberRepository;
    @Autowired
    private MemberServiceV4 memberService;

    @TestConfiguration
    @RequiredArgsConstructor
    static class TestConfig {

        // 스프링 빈에 있는 DataSource 를 주입받음.
        private final DataSource dataSource;

        @Bean
        MemberRepository memberRepositoryV3() {
            return new MemberRepositoryV4_1(dataSource);
        }

        @Bean
        MemberServiceV4 memberService() {
            return new MemberServiceV4(memberRepositoryV3());
        }
    }

테스트 코드 중 스프링빈 조립하는 부분만 변경.

정리
체크 예외를 런타임 예외로 변환하면서 인터페이스와 서비스 계층의 순수성을 유지할 수 있게 되었다.
덕분에 향후 JDBC에서 다른 구현 기술로 변경하더라도 서비스 계층의 코드를 변경하지 않고 유지할 수 있다.

남은 문제
리포지토리에서 넘어오는 특정한 예외의 경우 복구를 시도할 수도 있다. 그런데 지금 방식은 항상 MyDbException 이라는 예외만 넘어오기 때문에 예외를 구분할 수 없는 단점이 있다. 만약 특정 상황에는 예외를 잡아서 복구하고 싶으 면 예외를 어떻게 구분해서 처리할 수 있을까?
ex) 같은 아이디가 발생 -> 서비스에서 잡아서 아이디 추천하는 로직을 추가할 수도 그러나 지금은 예외 구분 불가.

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

데이터베이스 오류에 따라 특정 예외는 복구 필요할수도.
예를 들어서 회원 가입시 DB에 이미 같은 ID가 있으면 ID 뒤에 숫자를 붙여서 새로운 ID를 만들어야 한다고 가정해보자.
ID를 hello 라고 가입 시도 했는데, 이미 같은 아이디가 있으면 hello12345 와 같이 뒤에 임의의 숫자를 붙여서 가 입하는 것이다.

위에서 말한 아이디 중복이 발생할 때,
데이터 베이스에서 오류 코드를 반환하고,
이 오류 코드를 받은 JDBC드라이버가 SQLException 을 던짐.
그래서 SQLException 에는 데이터베이스에서 제공하는 errorCode 가 들어있음.

H2 데이터베이스의 키 중복 오류 코드

e.getErrorCode() == 23505 

이를 활용하면 데이터베이스에서 어떤 문제가 발생했는지 알 수 있음.

H2 데이터베이스 예
23505 : 키 중복 오류
42000 : SQL 문법 오류

참고로 같은 오류여도 각각의 데이터베이스마다 정의된 오류 코드가 다르다. 따라서 오류 코드를 사용할 때는 데이터베이스 메뉴얼을 확인해야 한다.

예) 키 중복 오류 코드

• H2 DB: 23505
• MySQL: 1062

H2 데이터베이스 오류 코드 참고
https://www.h2database.com/javadoc/org/h2/api/ErrorCode.html

그런데 이를 활용하려면 다시 SQLException 을 서비스 계층에 던져야함...

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

public class MyDuplicateKeyException extends MyDbException {
    public MyDuplicateKeyException() {
    }

    public MyDuplicateKeyException(String message) {
        super(message);
    }

    public MyDuplicateKeyException(String message, Throwable cause) {
        super(message, cause);
    }

    public MyDuplicateKeyException(Throwable cause) {
        super(cause);
    }
}

• MyDbException 을 상속받아 의미있는 계층을 형성한다. 이러면 데이터 베이스 관련 예외 계층을 만들 수 있음.
• 이름에도 의미를 담음
• 이 예외는 JDBC 나 JPA 같은 특정 기술에 종속적이지 않음. 따라서 이를 사용해도 서비스 계층의 순수함을 유지할 수 있음.

테스트 코드

@Slf4j
public class ExTranslatorV1Test {

    Repository repository;
    Service service;

    @BeforeEach
    void init() {
        DriverManagerDataSource dataSource = new DriverManagerDataSource(URL, USERNAME, PASSWORD);
        repository = new Repository(dataSource);
        service = new Service(repository);
    }

    @Test
    void duplicateKeySave() {
        service.create("myId");
        service.create("myId");// 같은 ID 저장 시도
    }

    @Slf4j
    @RequiredArgsConstructor
    static class Service {
        private final Repository repository;

        public void create(String memberId) {
            try {
                repository.save(new Member(memberId, 0));
            } catch (MyDuplicateKeyException e) {
                log.info("키 중복, 복구 시도");
                String retryId = generateNewId(memberId);
                log.info("retry key = {}", retryId);
                repository.save(new Member(retryId, 0));
            } catch (MyDbException e) {
                log.info("데이터 접근 계층 예외");
                throw e;
            }
        }

        private String generateNewId(String memberId) {
            return memberId + new Random().nextInt(10000);
        }
    }

    @RequiredArgsConstructor
    static class Repository {
        private final DataSource dataSource;

        public Member save(Member member) {
            String sql = "insert into member(member_id, money) values(?,?)";
            Connection con = null;
            PreparedStatement pstmt = null;
            try {
                con = dataSource.getConnection();
                pstmt = con.prepareStatement(sql);
                pstmt.setString(1, member.getMemberId());
                pstmt.setInt(2, member.getMoney());
                pstmt.executeUpdate();
                return member;
            } catch (SQLException e) {
                // h2
                if (e.getErrorCode() == 23505) {
                    throw new MyDuplicateKeyException(e);
                }
                throw new MyDbException(e);
            } finally {
                JdbcUtils.closeStatement(pstmt);
                JdbcUtils.closeConnection(con);
            }
        }
    }
}

실행해보면 2개가 저장된것 확인 가능.

리포지토리에서
키 중복 오류의 경우 MyDuplicateKeyException() 을 던짐.

서비스에서
MyDuplicateKeyException 이 온 경우 아이디를 새로 만들어 복구 시도함.

 try {
                repository.save(new Member(memberId, 0));
            } catch (MyDuplicateKeyException e) {
                log.info("키 중복, 복구 시도");
                String retryId = generateNewId(memberId);
                log.info("retry key = {}", retryId);
                repository.save(new Member(retryId, 0));
            } catch (MyDbException e) {
                log.info("데이터 접근 계층 예외");
                throw e;
            }

• 처음에 저장을 시도한다. 만약 리포지토리에서 MyDuplicateKeyException 예외가 올라오면 이 예외를 잡는다.
• 예외를 잡아서 generateNewId(memberId) 로 새로운 ID 생성을 시도한다. 그리고 다시 저장한다. 여기가 예 외를 복구하는 부분이다.
• 만약 복구할 수 없는 예외( MyDbException )면 로그만 남기고 다시 예외를 던진다.
  • 참고로 이 경우 여기서 예외 로그를 남기지 않아도 된다. 어차피 복구할 수 없는 예외는 예외를 공통으로 처 리하는 부분까지 전달되기 때문이다. 따라서 이렇게 복구 할 수 없는 예외는 공통으로 예외를 처리하는 곳에 서 예외 로그를 남기는 것이 좋다. 여기서는 다양하게 예외를 잡아서 처리할 수 있는 점을 보여주기 위해 이 곳에 코드를 만들어두었다.

정리

• SQL ErrorCode로 데이터베이스에 어떤 오류가 있는지 확인할 수 있었다.
• 예외 변환을 통해 SQLException 을 특정 기술에 의존하지 않는 직접 만든 예외인 MyDuplicateKeyException 로 변환 할 수 있었다.
• 리포지토리 계층이 예외를 변환해준 덕분에 서비스 계층은 특정 기술에 의존하지 않는 MyDuplicateKeyException 을 사용해서 문제를 복구하고, 서비스 계층의 순수성도 유지할 수 있었다.

남은 문제

• SQL ErrorCode는 각각의 데이터베이스 마다 다르다. 결과적으로 데이터베이스가 변경될 때 마다 ErrorCode 도 모두 변경해야 한다.
  예) 키 중복 오류 코드
  H2: 23505
  MySQL: 1062
• 데이터베이스가 전달하는 오류는 키 중복 뿐만 아니라 락이 걸린 경우, SQL 문법에 오류 있는 경우 등등 수십 수 백가지 오류 코드가 있다. 이 모든 상황에 맞는 예외를 지금처럼 다 만들어야 할까? 추가로 앞서 이야기한 것 처럼 데이터베이스마다 이 오류 코드는 모두 다르다.

[6om1n]

오 일찍 올려주셨네요 ~ 수고하셨습니다 !! 😃

[YuDeokRin]

수고하셧습니다 !

[seyxxn]

수고하셨습니당 ~~