[Spring] 스프링과 문제 해결 - 예외 처리, 반복

JJoSuk·2023년 6월 15일

본 프로젝트 자료는 김영한님의 스프링 DB 1편 - 데이터 접근 핵심 원리을 참고 제작됐음을 알립니다.

체크 예외와 인터페이스

서비스 계층이 특정 구현 기술에 의존하지 않고 순수한 계층으로 유지하고 싶다면 예외에 대한 의존도를 해결해야 한다.

그럼 어떻게 해야할까?

바로 SQLException 체크 예외를 런타임 예외로 전환해서 서비스 계층에 던지면 된다. 이렇게 하면 서비스 계층이 해당 예외를 무시할 수 있기 때문에, 특정 구현 기술에 의존하는 부분을 제거하고 서비스 계층을 순수하게 유지할 수 있다.

인터페이스 도입

이렇게 인터페이스를 도입하면 MemberService 는 MemberRepository 인터페이스에만 의존하면 된다.
이제 구현 기술을 변경하고 싶으면 DI를 사용해서 MemberService 코드의 변경 없이 구현 기술을 변경할 수 있다.

런타임 예외 적용

실제 코드에 런타임 예외를 사용하도록 적용해보자.

MemberRepository - 인터페이스 생성

MyDbException - 생성

MemberRepositoryV4_1 - 생성

하나씩 알아보자.

기존에 SQLException 으로 던지는 부분을 MyDbException 런타임 예외로 변환해서 던지고 있다.

MyDbException 이 내부에 SQLException 을 포함되어 있어 예외를 출력할 때 스택 트레이스를 통해 둘다 확인할 수 있다.
주의할 점은 SQLException 을 꼭 포함해서 예외처리 해야한다.
```
throw new MyDbException() x
```

MemberServiceV4 - 생성

서비스 에서도 throws SQLException 을 제거할 수 있게 됐다.

이제 테스트 코드를 통해 제대로 동작하는지만 확인하면 된다.

MemberServiceV4Test - 테스트 생성

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

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

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

예를 들어서 회원 가입시 DB에 이미 같은 ID가 있으면 ID 뒤에 숫자를 붙여서 새로운 ID를 만들어야 한다고 가정해보자.
ID를 hello 라고 가입 시도 했는데, 이미 같은 아이디가 있으면 hello12345 와 같이 뒤에 임의의 숫자를 붙여서 가입하는 것이다.

데이터를 DB에 저장할 때 같은 ID가 이미 데이터베이스에 저장되어 있다면, 데이터베이스는 오류 코드를 반환하고, 이 오류 코드를 받은 JDBC 드라이버는 SQLException 을 던진다.
그리고 SQLException 에는 데이터베이스가 제공하는 errorCode 라는 것이 들어있다.

데이터베이스 오류 코드 그림

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

e.getErrorCode() == 23505

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

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

서비스 계층에서는 예외 복구를 위해 키 중복 오류를 확인할 수 있어야 한다.
그래야 새로운 ID를 만들어서 다시 저장을 시도할 수 있기 때문이다.
이러한 과정이 바로 예외를 확인해서 복구하는 과정이다.
리포지토리는 SQLException 을 서비스 계층에 던지고 서비스 계층은 이 예외의 오류 코드를 확인해서 키 중복 오류( 23505 )인 경우 새로운 ID를 만들어서 다시 저장하면 된다.

그런데 SQLException 에 들어있는 오류 코드를 활용하기 위해 SQLException 을 서비스 계층으로 던지게 되면, 서비스 계층이 SQLException 이라는 JDBC 기술에 의존하게 되면서, 지금까지 우리가 고민했던 서비스 계층의 순수성이 무너진다.

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

```
SQLException -> MyDuplicateKeyException
```

위 문제를 코드를 통해 예습해보자.

MyDuplicateKeyException - 생성

기존에 사용했던 MyDbException 을 상속받아서 의미있는 계층을 형성한다. 이렇게하면 데이터베이스 관련 예외라는 계층을 만들 수 있다.
그리고 이름도 MyDuplicateKeyException 이라는 이름을 지었다. 이 예외는 데이터 중복의 경우에만 던져야 한다.
이 예외는 우리가 직접 만든 것이기 때문에, JDBC나 JPA 같은 특정 기술에 종속적이지 않다. 따라서 이 예외를 사용하더라도 서비스 계층의 순수성을 유지할 수 있다. (향후 JDBC에서 다른 기술로 바꾸어도 이 예외는 그대로 유지할 수 있다.)

테스트 코드를 통해 확인해보자.

ExTranslatorV1Test - 테스트 생성

실행해보면 다음과 같은 실행 로그를 확인할 수 있다.

같은 ID를 저장했지만, 중간에 예외를 잡아서 복구한 것을 확인할 수 있다.

리포지토리 부터 중요한 부분을 살펴보자.

e.getErrorCode() == 23505 : 오류 코드가 키 중복 오류( 23505 )인 경우 MyDuplicateKeyException 을 새로 만들어서 서비스 계층에 던진걸 확인할 수 있다.
나머지 경우 기존에 만들었던 MyDbException 을 던진다.

서비스의 중요한 부분을 살펴보자.

처음에 저장을 시도한다. 만약 리포지토리에서 MyDuplicateKeyException 예외가 올라오면 이 예외를 잡는다.
예외를 잡아서 generateNewId(memberId) 로 새로운 ID 생성을 시도한다. 그리고 다시 저장한다. 여기가 예외를 복구하는 부분이다.
만약 복구할 수 없는 예외( MyDbException )면 로그만 남기고 다시 예외를 던진다.

참고로 이 경우 여기서 예외 로그를 남기지 않아도 된다.
어차피 복구할 수 없는 예외는 예외를 공통으로 처리하는 부분까지 전달되기 때문이다.

따라서 이렇게 복구 할 수 없는 예외는 공통으로 예외를 처리하는 곳에서 예외 로그를 남기는 것이 좋다. 여기서는 다양하게 예외를 잡아서 처리할 수 있는 점을 보여주기 위해 이곳에 코드를 만들어두었다.

스프링 예외 추상화 이해

스프링은 데이터 접근과 관련된 예외를 추상화해 문제를 해결한다.

다음과 같이 특정 기술에 종속된 예외를 사용하기보다, 특정 기술에 종속되어 있지 않는 예외를 사용하는 것을 추천한다. 스프링에서 제공해준다.
특정 기술(JDBC, JPA 등) 를 사용할 때 발생하는 예외도 스프링에서 제공해주는 예외로 변환하여 해결 할 수 있다.
그림 이외에도 더 많은 예외들이 존재한다.
DataAccessException 는 최고상위 예외이다. 그림과 같이 스프링이 제공하는 데이터 접근 계층의 모든 예외는 런타임 예외이다.
런타임 예외 혹은 DataAccessException 예외에는 크게 2가지 특징이 있는데, NonTransient 예외와 Transient 예외가 바로 그 예외다.
- NonTransient 는 말 그대로 일시적이지 않다는 뜻이다. 같은 SQL(오류) 을 반복적으로 수행하면 안된다는 의미다.
- Transient 는 위와 반대로 일시적이라는 뜻이다. 이 역시 위와 반대로 SQL 을 다시 시도했을 때 성공할 가능성이 있다.
  - 예를 들어 데이터베이스의 상태가 안좋아졌다가 좋아지거나, 락이 풀렸는데 다시 시도하면 성공한다는가 등.