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

[newh08]

언체크 예외 기본 이해

RuntimeException 과 그 하위 예외는 언체크 예외로 분류된다.
언체크 예외는 말 그대로 컴파일러가 예외를 체크하지 않는다는 뜻이다.
언체크 예외는 체크 예외와 기본적으로 동일(모든 예외는 잡아서 처리 or 던지기 해야함)
차이가 있다면 예외를 던지는 throws 를 선언하지 않고, 생략 할 수 있다. 이 경우 자동으로 예외를 던진다.

체크 예외 VS 언체크 예외
체크 예외: 예외를 잡아서 처리하지 않으면 항상 throws 에 던지는 예외를 선언해야 한다.
언체크 예외: 예외를 잡아서 처리하지 않아도 throws 를 생략할 수 있다. 생략해도 자동으로 밖으로 던짐

언체크 예외 테스트 코드

@Slf4j
public class UncheckedTest {

    @Test
    void checked_catch() {
        Service service = new Service();
        service.callCatch();
        // 체크 예외를 잡았으므로 테스트 정상 종료
    }

    @Test
    void checked_throw() {
        Service service = new Service();
        Assertions.assertThatThrownBy(service::callThrow)
                .isInstanceOf(MyUncheckedException.class);
    }

    /**
     * RuntimeException 을 상속받은 예외는 언체크 예외이다.
     */
    static class MyUncheckedException extends RuntimeException {
        public MyUncheckedException(String message) {
            super(message);
        }
    }

    /**
     * Unchecked 예외는 예외를 잡거나 던지지 않아도 된다.
     * 예외를잡지 않으면 자동으로 던진다.
     */

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

        /**
         * 필요한 경우 예외를 잡아서 치라하면 된다.
         */
        public void callCatch() {
            try {
                repository.call();
            } catch (MyUncheckedException e) {
                // 예외 처리 로직
                log.info("예외 처리, message={}", e.getMessage(), e);
            }
        }

        /**
         * 에외를 잡지 않아도, 상위로 던짐
         * 체크예외와 다르게 throws 선언하지 않아도 됨.
         */
        public void callThrow() {
            repository.call();
        }
    }

    static class Repository {
        public void call()  { // throw 선언해도 되지만 선언하지 않아도 괜찮음.
            throw new MyUncheckedException("ex");
        }
    }

언체크 예외를 밖으로 던지는 코드

 public void callThrow() throws MyUncheckedException {
     repository.call();
}

• 참고로 언체크 예외도 throws 예외 를 선언해도 된다. 물론 생략할 수 있다.
• 언체크 예외는 주로 생략하지만, 중요한 예외의 경우 이렇게 선언해두면 해당 코드를 호출하는 개발자가 이런 예 외가 발생한다는 점을 IDE를 통해 좀 더 편리하게 인지할 수 있다.(컴파일 시점에 막을 수 있는 것은 아니고, IDE 를 통해서 인지할 수 있는 정도이다.)

언체크 예외의 장단점
언체크예외는예외를잡아서처리할수없을때,예외를밖으로던지는 throws 예외 를생략할수있다. 이것때문에 장점과 단점이 동시에 존재한다.

• 장점: 신경쓰고 싶지 않은 언체크 예외를 무시할 수 있다. 체크 예외의 경우 처리할 수 없는 예외를 밖으로 던지려 면 항상 throws 예외 를 선언해야 하지만, 언체크 예외는 이 부분을 생략할 수 있다. 이후에 설명하겠지만, 신경 쓰고 싶지 않은 예외의 의존관계를 참조하지 않아도 되는 장점이 있다.

• 단점: 언체크 예외는 개발자가 실수로 예외를 누락할 수 있다. 반면에 체크 예외는 컴파일러를 통해 예외 누락을 잡아준다.

두 예외의 차이는 예외를 처리할 수 없을 경우에 던지는 선언을 필수로 해야하는가, 아닌가에 있다.
차이점은 단순하지만 이를 활용할때 어마어마한 차이가 있음.

체크 예외 활용

앞으로 언체크 예외를 런타임 예외로 말하겠다.

그럼 체크, 런타임 예외를 어떻게 사용해야할까?

어떤 문제가 있을때 하나하나 살펴보면서 해결하는 것 보단,
대원칙을 세우면 많은 부분이 해결되는 경우가 많다.
이것을 예외 활용에도 적용!

기본 원칙은 다음 2가지를 기억하자.

1. 기본적으로 언체크(런타임) 예외를 사용하자.
2. 체크 예외는 비즈니스 로직상 의도적으로 던지는 예외에만 사용하자.
   • 이 경우 해당 예외를 잡아서 반드시 처리해야 하는 문제일 때만 체크 예외를 사용해야 한다. 예를 들어서 다 음과 같은 경우가 있다.
     • 체크 예외 예)
     • 계좌 이체 실패 예외
     • 결제시 포인트 부족 예외
     • 로그인 ID, PW 불일치 예외
     • 물론 이런 경우도 무조건 체크예외로 만들어야 하는건 아님. 다만 심각한 문제는 개발자가 실수로 예외를 놓치면 안되기 때문에 이런 경우 체크 예외로 만들면 컴파일러를 통해 놓친 예외를 인지할 수 있음.

체크 예외의 문제점
체크 예외는 컴파일러가 예외 누락을 체크해주기 때문에 개발자가 실수로 예외를 놓치는 것을 막아준다. 그래서 항상 명 시적으로 예외를 잡아서 처리하거나, 처리할 수 없을 때는 예외를 던지도록 method() throws 예외 로 선언해야 한다.
-> 아주 좋아 보이는데 왜 체크예외를 사용하지 말라고 할까?

리포지토리(DB 접근)에서 SQLException 체크예외 던짐.
네트워크클라이언트 (외부 네트워크 접속) 에서 ConnectException 체크예외 던짐
서비스는 리포지토리와 네트워크클라이언트 호출
- 따라서 두곳에서 올라오는 SQLException, ConnectException 처리해야함.
- 그런데 서비스에선 이를 처리할 수 없음! 서비스에서 데이터베이스에서 발생한 문제나 네트워크 연결 문제를 해결할 수 없기 때문.

• 그래서 둘 다 던질수밖에..

• method() throws SQLException, ConnectException 이렇게 선언해야함. 서비스 입장에선 알고싶지 않은데, 무조건 선언해야함.
  이는 컨트롤러에서 처리할 방법이 없음. 서비스와 동일
  이런 경우 웹 어플리케이션이라면 서블릿의 오류 페이지나, 스프링 MVC 가 제공하는 ControllerAdvice 에서 공통으로 처리.

• 이런 문제들은 보통 사용자에게 어떤 문제가 발생했는지 자세히 설명하기가 어렵다. 그래서 사용자에게는 "서비스에 문제가 있습니다." 라는 일반적인 메시지를 보여준다. ("데이터베이스에 어떤 오류가 발생했어요" 라고 알려주어도 일반 사용자가 이해할 수 없다. 그리고 보안에도 문제가 될 수 있다.)

• API라면 보통 HTTP 상태코드 500(내부 서버 오류)을 사용해서 응답을 내려준다.

• 이렇게 해결이 불가능한 공통 예외는 별도의 오류 로그를 남기고, 개발자가 오류를 빨리 인지할 수 있도록 메일, 알림(문자, 슬랙)등을 통해서 전달 받아야 한다. 예를 들어서 SQLException 이 잘못된 SQL을 작성 해서 발생했다면, 개발자가 해당 SQL을 수정해서 배포하기 전까지 사용자는 같은 문제를 겪게 된다.

테스트 코드

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가지 문제
지금까지 설명한 예시와 코드를 보면 크게 2가지 문제를 알 수 있다.

1. 복구 불가능한 예외

2. 의존 관계에 대한 문제

3. 복구 불가능 예외
   대부분의 예외는 복구가 불가능하다. 일부 가능하지만 아주 적음.
   예를들어 SQLException 은 데이터베이스에서 발생한 문제인데, SQL 문법에 문제가 있을 수 있고, 데이터베이스 자체에 문제가 있을 수 있음.
   이는 복구 불가능한 예외. 이런 문제는 일관성 있게 공통으로 처리해야함. 오류 로그를 남기고 개발자가 해당 오류를 빨리 인지하는 것이 필요.
   서블릿 필터, 스프링 인터셉터, 스프링의 ControllerAdvice 를 사용하면 이부분을 깔끔하게 공통으로 해결할 수 있음.

4. 의존 관계에 대한 문제
   예외에 대한 의존관계 문제. 서비스나 컨트롤러는 처리할 수 없어도 어쩔수 없이 throws 로 예외를 선언해야함.
   즉 서비스나 컨트롤러에서 던지는 예외에 의존하게됨.

위 예시에선 서비스, 컨트롤러에서 java.sql.SQLException 을 의존하기 때문에 문제가 된다.

향후에 기술을 JDBC 기술이 아닌 다른 기술로 변경하면, 모든 코드를 바꿔야함.

서비스나 컨트롤러 입장에서는 어차피 본인이 처리할 수 도 없는 예외를 의존해야 하는 큰 단점이 발생하게 된다. 결과적으로 OCP, DI를 통해 클라이언트 코드의 변경 없이 대상 구현체를 변경할 수 있다는 장점이 체크 예외 때문에 발목을 잡게 된다.

JDBC -> JPA 로 기술을 변경하면 예외 변경 및 해당 예외를 던지는 부분도 함께 변경해야함.

처리할 수 없는 체크예외는 던질수 밖에 없고 이러면 서비스나 컨트롤러까지 해당 예외를 알고있어야함.

그러면 그냥 throws Exception 하면???
의존관계는 없앨 수 있으나 이는 모든 체크예외를 하나로 묶어버리므로
의도한 다른 체크 예외의 기능이 무효화됨. 중요한 체크 예외를 다 놓침
꼭 필요한 경우가 아니라면 사용 하지 말자.

언체크 예외 활용

런타임 예외를 사용해보자.

• SQLException 을 런타임 예외인 RuntimeSQLException 으로 변환했다.
• ConnectException 대신에 RuntimeConnectException 을 사용하도록 바꾸었다.
• 런타임 예외이기 때문에 서비스, 컨트롤러는 해당 예외들을 처리할 수 없다면 별도의 선언 없이 그냥 두면 된다.

public class UncheckedAppTest {

    @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()  {
            repository.call();
            networkClient.call();
        }
    }

    static class NetworkClient {
        public void call()   {
            try {
                connect();
            } catch (ConnectException e) {
                throw new RuntimeConnectionException(e);
            }
        }

        public void connect() throws ConnectException {
            throw new ConnectException("연결 실패");
        }
    }

    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 RuntimeConnectionException extends RuntimeException {
        public RuntimeConnectionException(Throwable cause) {
            super(cause);
        }
    }

    static class RuntimeSQLException extends RuntimeException {
        public RuntimeSQLException(Throwable cause) {
            super(cause);
        }
    }
}

예외 전환
리포지토리에서 체크 예외인 SQLException 이 발생하면 런타임 예외인 RuntimeSQLException 으로 전환 해서 예외를 던진다.
참고로 이때 기존 예외를 포함해주어야 예외 출력시 스택 트레이스에서 기존 예외도 함께 확인할 수 있다.
예외 포함에 대한 부분은 조금 뒤에 더 자세히 설명한다.

NetworkClient 는 단순히 기존 체크 예외를 RuntimeConnectException 이라는 런타임 예외가 발생하도록 코드를 바꾸었다.

런타임 예외 - 대부분 복구 불가능한 예외
시스템에서 발생한 예외는 대부분 복구 불가능 예외이다. 런타임 예외를 사용하면 서비스나 컨트롤러가 이런 복구 불가 능한 예외를 신경쓰지 않아도 된다. 물론 이렇게 복구 불가능한 예외는 일관성 있게 공통으로 처리해야 한다.

런타임 예외 - 의존 관계에 대한 문제
런타임 예외는 해당 객체가 처리할 수 없는 예외는 무시하면 된다. 따라서 체크 예외 처럼 예외를 강제로 의존하지 않아 도 된다.

기술 변경시 리포지토리와 네트워크클라이언트에서 예외 변경,
예외를 처리하는 공통처리 에서만 변경 발생.
컨트롤러, 서비스에서는 코드 변경 X

처음 자바가 나왔을땐 체크예외가 더 좋을거라 생각.
컴파일러가 체크해주니 당연!
그래서 자바 기본 기능엔 체크 예외가 많음.
그러나 시간이 지날수록 복구할수 없는 예외 + 라이브러리 사용에 따라 처리해야하는 예외가 늘어남.
라이브러리에서 예외를 처리할 수 없을떄 모두 throws 를 함. 극단적인 경우 throws Exception 도 사용함 (이럼 안된다)

체크 예외의 이런 문제점 때문에 최근 라이브러리들은 대부분 런타임 예외를 기본으로 제공한다. JPA 기술도 런타임 예외를 사용한다. 스프링도 대부분 런타임 예외를 제공한다.
런타임 예외도 필요하면 잡을 수 있기 때문에 필요한 경우에는 잡아서 처리하고, 그렇지 않으면 자연스럽게 던지도록 둔 다. 그리고 예외를 공통으로 처리하는 부분을 앞에 만들어서 처리하면 된다.

추가로 런타임 예외는 놓칠 수 있기 때문에 문서화가 중요하다.

런타임 예외는 문서화
런타임 예외는 문서화를 잘해야 한다.
또는 코드에 throws 런타임예외 을 남겨서 중요한 예외를 인지할 수 있게 해준다.

JPA EntityManager

/**
 * Make an instance managed and persistent.
 * @param entity  entity instance
 * @throws EntityExistsException if the entity already exists.
 * @throws IllegalArgumentException if the instance is not an
 *         entity
 * @throws TransactionRequiredException if there is no transaction when
 *         invoked on a container-managed entity manager of that is of type
 *         <code>PersistenceContextType.TRANSACTION</code>
 */
public void persist(Object entity); 

예) 문서에 예외 명시

스프링 JdbcTemplate

 /**
  * Issue a single SQL execute, typically a DDL statement.
  * @param sql static SQL to execute
  * @throws DataAccessException if there is any problem
  */
void execute(String sql) throws DataAccessException; 

예) method() throws DataAccessException 와 같이 문서화 + 코드에도 명시

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

예외 포함과 스택 트레이스

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

    @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) 지금 예에서는 파라미터가 없기 때문에, 예외만 파라미터에 전달하면 스택 트레이스를 로그에 출력할 수 있다.

기존 예외를 포함하는 경우

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

이 로그가 남음.

Caused by: java.sql.SQLException: EX
	at hello.jdbc.exception.UncheckedAppTest$Repository.runSQL(UncheckedAppTest.java:62)
	at hello.jdbc.exception.UncheckedAppTest$Repository.call(UncheckedAppTest.java:55)
	... 88 common frames omitted

실무에선 이 기존 예외를 포함하지 않는 실수를 많이함.

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

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

hello.jdbc.exception.basic.UncheckedAppTest$RuntimeSQLException: null
at hello.jdbc.exception.basic.UncheckedAppTest$Repository.call(UncheckedAppTest.jav a:61)
at hello.jdbc.exception.basic.UncheckedAppTest$Service.logic(UncheckedAppTest.java:45)

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

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