[스프링 DB 1편] #5. 자바 예외 이해 (2)

[6om1n]

#️⃣ 목차

• 체크 예외 활용
• 언체크 예외 활용
• 예외 포함과 스택 트레이스

---

1️⃣ 체크 예외 활용

언제 체크 예외를 쓰는지, 언체크예외를 쓰는지, 기본 원칙 2가지

• 기본적으로는 언체크(런타임) 예외를 사용하자
• 체크 예외는 비즈니스 로직 상 의도적으로 던지는 예외에만 사용하자
  • 해당 예외를 반드시 잡아서 처리해야 하는 문제일 때만 체크 예외를 사용해야 한다.
  • 체크 예외 예시
    • 계좌 이체 실패 예외
    • 결제 시 포인트 부족 예외
    • 로그인 ID, PW 불일치 예외

체크 예외 문제점

• Repository 는 DB에 접근해서 데이터를 저장하고 관리한다. 위의 그림에서는 SQLException 체크 예외를 던진다.

• NetworkClient 는 외부 네트워크에 접속해서 어떤 기능을 처리하는 객체이다. 여기서 ConnectException 체크 예외를 던진다.

• 서비스는 Repository 와 NetworkClient 를 둘 다 호출한다.

  • 따라서 두 곳에서 올라오는 체크 예외인 SQLException 과 ConnectException 을 처리해야 한다.
  • 그러나 서비스는 이 둘을 처리할 방법을 모른다. ConnectException 처럼 연결이 실패하거나 SQLException 처럼 데이터베이스에서 발생하는 문제들은 대부분 애플리케이션 로직에서 처리할 방법이 없다.

• 서비스는 SQLException 과 ConnectException 을 처리할 수 없으므로 둘 다 밖으로 던진다.

• 컨트롤러도 두 예외를 처리할 방법이 없다.

• 웹 애플리케이션이라면 서블릿의 오류 페이지나 또는 스프링 MVC가 제공하는 ControllerAdvice 에서 이런 예외를 공통으로 처리한다.

  • 사용자에게 어떤 문제가 발생했는지 자세히 설명하기 어려우므로 "서비스에 문제가 있습니다" 라는 일반적인 메시지를 보여준다. (보안에도 문제가 될 수 있기 때문)
  • API 라면 HTTP 상태코드 500(내부 서버 오류) 를 사용해서 응답을 내려준다.
  • 이렇게 해결이 불가능한 공통 예외는 별도의 오류 로그를 남기고, 개발자가 오류를 빨리 인지할 수 있도록 메일, 알림등을 통해서 전달 받아야 한다.

• 체크 예외 문제점 - 코드 - CheckedAppTest

package hello.jdbc.exception.basic;

import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;

import java.net.ConnectException;
import java.sql.SQLException;

public class CheckedAppTest {

    @Test
    void checked() {
        Controller controller = new Controller();
        Assertions.assertThatThrownBy(() -> controller.request())
                .isInstanceOf(Exception.class);
    }

    static class Controller {
        Service service = new Service();

        public void request() throws SQLException, ConnectException {
            service.logic();
        }
    }

    static class Service {
        Repository repository = new Repository();
        NetworkClient networkClient = new NetworkClient();

        public void logic() throws SQLException, ConnectException {
            repository.call();
            networkClient.call();
        }
    }

    static class NetworkClient{
        public void call() throws ConnectException {
            throw new ConnectException("연결 실패");
        }
    }

    static class Repository {
        public void call() throws SQLException {
            throw new SQLException("ex");
        }
    }
}

• 서비스
  • 체크 예외를 처리하지 못해서 밖으로 던지기 위해 logic() throws SQLException, ConnectException 을 선언했다.
• 컨트롤러
  • 체크 예외를 처리하지 못해서 밖으로 던지기 위해 request() throws SQLException, ConnectException 을 선언했다.

위의 예시는 2가지 문제점이 존재한다.

• 1. 복구 불가능한 예외
• 2. 의존 관게에 대한 문제

1. 복구 불가능한 예외

• 대부분의 예외는 복구가 불가능하다. 일부 복구가 가능한 예외도 있지만 아주 적다.
• SQLException 은 데이터베이스에서 무언가 문제 (SQL 문법 오류, 데이터베이스 자체 오류 ..) 가 있어서 발생하는 예외이므로 대부분 복구가 불가능하다. 특히 대부분의 서비스나 컨트롤러는 문제를 해결할 수 없다.
• 이런 문제들은 일관성 있게 공통으로 처리해야 한다. 서블릿 필터, 스프링 인터셉터, 스프링의 ControllerAdvice 를 사용하면 이런 부분을 깔끔하게 공통으로 해결할 수 있다.

2. 의존 관계에 대한 문제

• 체크 예외이기 때문에 컨트롤러나 서비스는 본인이 처리할 수 없어도 어쩔 수 없이 throws 를 통해 던지는 예외를 선언해야 한다.
• 예외를 던지는 부분을 코드에 선언하는 것이 문제가 되는 이유는 서비스, 컨트롤러에서 java.sql.SQLException 을 의존하기 때문이다.
• 나중에 리포지토리를 JDBC가 아닌 다른 기술로 변경한다면, SQLException 이 아니라 예를 들어 JPAException 으로 예외가 변경된다면 모든 서비스, 컨트롤러의 코드를 JPAException 에 의존하도록 고쳐야하는 문제점이 있다.
  

📍 정리

• 처리할 수 있는 체크 예외라면 서비스나 컨트롤러에서 처리하겠지만, 데이터베이스나 네트워크 통신처럼 시스템 레벨에서 올라온 예외들은 대부분 복구가 불가능하다. 실무에서 발생하는 대부분의 예외들은 이런 시스템 예외들이다.
• 체크 예외를 사용하면 아래에서 올라온 복구 불가능한 예외를 서비스, 컨트롤러 같은 각각의 클래스가 모두 알고 있어야 한다. 그래서 불필요한 의존관계 문제가 발생하게 된다.

throws Exception

• throws SQLException 이 아니라 throws Exception 처럼 최상위 예외를 던질 수도 있다. 그러나 모든 체크 예외를 다 밖으로 던지는 문제가 발생한다.
• 따라서 꼭 필요한 경우가 아니면 Exception 자체를 밖으로 던지는 것은 좋지 않은 방법이다.

---

2️⃣ 언체크 예외 활용

런타임 예외 사용

• SQLExceptino 을 런타임 예외인 RuntimeSQLException 으로 변환했다.

• ConnectException 대신에 RuntimeConnectException 을 사용하도록 바꾸었다.

• 런타임 예외이기 때문에 서비스, 컨트롤러는 해당 예외들을 처맇라 수 없다면 별도의 선언 없이 그냥 두면 된다.

• 런타임 예외 사용 변환 - 코드 - UncheckedAppTest

package hello.jdbc.exception.basic;

import lombok.extern.slf4j.Slf4j;
import org.assertj.core.api.Assertions;
import org.junit.jupiter.api.Test;

import java.sql.SQLException;

@Slf4j
public class UnCheckedAppTest {

    @Test
    void unchecked() {
        Controller controller = new Controller();
        Assertions.assertThatThrownBy(() -> controller.request())
                .isInstanceOf(Exception.class);
    }

    @Test
    void printEx(){
        Controller controller = new Controller();
        try {
            controller.request();
        } catch (Exception e) {
            //e.printStackTrace();
            log.info("ex", e);
        }
    }

    static class Controller {
        Service service = new Service();

        public void request() {
            service.logic();
        }
    }

    static class Service {
        Repository repository = new Repository();
        NetworkClient networkClient = new NetworkClient();

        public void logic() {
            repository.call();
            networkClient.call();
        }
    }

    static class NetworkClient {
        public void call() {
            throw new RuntimeConnectException("연결 실패");
        }
    }

    static class Repository {
        public void call() {
            try {
                runSQL();
            } catch (SQLException e) {
                throw new RuntimeSQLException(e);
            }
        }
        public void runSQL () throws SQLException {
            throw new SQLException("ex");
        }
    }
    static class RuntimeConnectException extends RuntimeException {
        public RuntimeConnectException(String messages) {
            super(messages);
        }
    }

    static class RuntimeSQLException extends RuntimeException {
        public RuntimeSQLException() {

        }

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

• 리포지토리에서 체크 예외인 SQLException 이 발생하면 런타임 예외인 RuntimeSQLException 으로 전환해서 예외를 던진다.
• NetworkClient 는 단순히 기존 체크 예외를 RuntimeConnectException 이라는 런타임 예외가 발생하도록 코드를 바꾸었다.
• 시스템에서 발생하는 예외는 대부분 복구 불가능 예외이다. 런타임 예외를 사용하면 서비스, 컨트롤러가 이런 복구 불가능한 예외를 신경쓰지 않아도 된다.
• 또한 런타임 예외는 해당 객체가 처리할 수 없는 예외는 무시하면 된다. 따라서 체크 예외처럼 예외를 강제로 의존하지 않아도 된다.

런타임 예외 구현 기술 변경 시 파급 효과

• 런타임 예외를 사용하면 중간에 기술이 변경되어도 해당 예외를 사용하지 않는 컨트롤러, 서비스에서는 코드를 변경하지 않아도 된다.
• 구현 기술이 변경되는 경우, 예외를 공통으로 처리하는 곳에서 예외에 따른 다른 처리가 필요할 수 있다. 하지만 공통 처리하는 한 곳만 변경하면 되기 때문에 변경의 영향 범위는 최소화 된다.

📍 정리

• 시간이 흐를수록 복구 할 수 없는 예외가 너무 많아졌기에 체크 예외를 사용해서 throws 에 예외를 계속 붙여야 했다.
• 이런 체크 예외의 문제점 때문에 최근 라이브러리들은 대부분 런타임 예외를 기본으로 제공한다. JPA 기술도 런타임 예외를 사용한다. 스프링도 대부분 런타임 예외를 제공한다.
• 런타임 예외도 필요하면 잡을 수 있기 때문에 필요한 경우에는 잡아서 처리하고, 그렇지 않으면 자연스럽게 던지도록 둔다. 그리고 예외를 공통으로 처리하는 부분을 앞에 만들어서 처리하면 된다.
• 런타임 예외는 문서화를 잘 해야한다. 또는 코드에 throws 런타임예외 를 남겨서 중요한 예외를 인지할 수 있게 해준다.

런타임 예외 문서화 예시

• JPA Entity Manager
  

• 스프링 JdbcTemplate
  

• 런타임 예외도 throws 에 선언할 수 있다. 물론 생략해도 된다.
• 던지는 예외가 명확하고 중요하다면, 코드에 어떤 예외를 던지는지 명시되어 있기 때문에 개발자가 IDE를 통해서 예외를 확인하기가 편리하다.
• 컨트롤러나 서비스에서 DataAccessException 을 사용하지 않는다면 런타임 예외이기 때문에 무시해도 된다.

---

3️⃣ 예외 포함과 스택 트레이스

예외를 전환할 때는 꼭 기존 예외를 포함해야 한다. 그렇지 않으면 스택 트레이스를 확인할 때 심각한 문제가 발생한다.

 @Test
    void printEx(){
        Controller controller = new Controller();
        try {
            controller.request();
        } catch (Exception e) {
            //e.printStackTrace();
            log.info("ex", e);
        }
    }

• 로그를 출력할 때 마지막 파라미터에 예외를 넣어주면 로그에 스택 트레이스를 출력할 수 있다.

  • log.info("message={}", "message" , ex) 여기에서 마지막에 ex 를 전달하는 것을 확인할 수 있다. 이렇게하면 스택 트레이스에 로그를 출력할 수 있다.
  • log.info("ex", ex) 지금 예에서는 파라미터가 없기 때문에, 예외만 파라미터에 전달하면 스택트레이스를 로그에 출력할 수 있다.

• System.out 에 스택 트레이스를 출력하려면 e.printStackTrace() 를 사용하면 된다.

  • 실무에서는 항상 로그를 사용해야 한다.

• 기존 예외를 포함하는 경우

  public void call() {
            try {
                runSQL();
            } catch (SQLException e) {
                throw new RuntimeSQLException(e);
            }
        }

• 예외를 포함해서 기존에 발생한 java.sql.SQLException 과 스택 트레이스를 확인할 수 있다.

• 기존 예외를 포함하지 않는 경우

 public void call() {
            try {
                runSQL();
            } catch (SQLException e) {
                throw new RuntimeSQLException();
            }
        }

• 예외를 포함하지 않아서 기존에 발생한 java.sql.SQLException 과 스택 트레이스를 확인할 수 없다.
• 변환한 RuntimeSQLException 부터 예외를 확인할 수 있다. 만약 실제 DB에 연동했다면 DB에서 발생한 예외를 확인할 수 없는 심각한 문제가 발생한다.

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

---

🔗 출처
김영한 - 스프링 DB 1편 - 데이터 접근 핵심 원리

---