37. 스프링으로 예외처리, 반복 해결 체크예외

먼저 체크예외로 해결하려는 시도를 한다.. 안 좋긴 하지만 시키려는 모양이다.

 

우리가 먼저, 

@Transactional
public void accountTransfer(String fromId, String toId, int money) throws SQLException {
    Member fromMember = memberRepository.findById(fromId);
    Member toMember = memberRepository.findById(toId);

    memberRepository.update(fromId, fromMember.getMoney() - money);
    validation(toMember);
    memberRepository.update(toId, toMember.getMoney() + money);
}

트랜잭션 애노테이션을 이용하여 트랜잭션에 관한 코드는 더 이상 의존하지 않고, 서비스도 순수 비즈니스 로직만 남겨두도록 짰다.

 

근데 문제가 하나, JDBC기술의 예외인 SQLException을 의존한다.

 

 

리포지토리에서 런타임예외로 바꾸어 던져, 예외를 컴파일러가 무시할 수 있도록 해보자.

 

그리고, 현재 의존을 구현체에 의존하고 있으니,

이렇게 인터페이스를 의존하게 하고, 그걸 확장시켜 만약 Jdbc기술에서 Jpa로 갈아 끼워도 서비스의 비즈니스 로직을 전혀 바꿀 필요가 없게된다.

 

 

근데 좀 문제가 있다.

 

구현체가 예외를 던지는 거라면, 인터페이스 또한 예외를 던져야 한다. 뭔가 인터페이스라도 인자라던지 반환타입은 맞춰야 된다던지 그런 것과 비슷한 결 인것 같다.

근데 게다가 SQLException은 체크 예외라 여지가 없다.

보통은 인터페이스 먼저 만들고 구현체를 만들게 되는데, 구현체를 만들면서 예외를 던지게 된다면 컴파일이 체크한다.

 

 

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

이런 식으로 해야 하게 된다.

그렇다고 의존성 없앤다고 Exception으로 하는 것도 안좋은 방법이다.

 

결과적으로 인터페이스 자체도 특정 기술에 의존하게 된다.

 

 

 

그럼 어떻게 해야 하냐?

그냥 간단하다. 런타임 예외로 변경해서 던지게끔 하면 된다.