체크 예외, 언체크 예외

이 글은 김영한 님의 "스프링 DB 1편 - 데이터 접근 핵심 원리" 강의에 기반하여 쓰였습니다.

 

 

 

스프링이 제공하는 예외 추상화를 이해하기 위해서는 자바 기본 예외에 대한 이해가 필요하다.

 

 

예외 계층

자바의 모든 객체의 최상위 부모는 object이다. 따라서 예외의 최상위 부모도 object이다. Throwable은 최상위 예외로 하위에 Exception과 Error가 있다. Error는 애플리케이션에서 복구가 불가능한 시스템 예외로 애플리케이션 개발자는 이 예외를 잡으려고 해서는 안된다. 상위 예외를 catch로 잡으면 그 하위 예외까지 함께 잡는다. 따라서 애플리케이션 로직에서는 Throwable 예외도 잡으면 안 되는데, Error 예외도 함께 잡을 수 있기 때문이다. 애플리케이션 로직은 이러한 이유로 Exception부터 필요한 예외로 생각하고 잡으면 된다. (Error도 언체크 예외)

Exception은 체크 예외로 애플리케이션 로직에서 사용할 수 있는 실질적인 최상위 예외이다. Exception과 하위 예외는 모두 컴파일러가 체크하는 예외이다. 단, RuntimeExcepton은 예외로 한다. RuntimeException은 컴파일러가 체크하지 않는 언체크 예외, 런타임 예외이다. RuntimeException과 그 자식 예외는 모두 언체크 예외이며 런타임 예외라고 많이 부른다.

 

기본적으로 예외는 잡아서(catch) 처리하거나 던져야(throws) 한다. 예외를 잡거나 던질 때 지정한 예외뿐만 아니라 하위의 자식들도 함께 처리된다. Exception을 catch로 잡으면 하위 예외들도 모두 잡을 수 있으며, throws로 던지면 그 하위 예외들도 모두 던질 수 있다.

 

체크 예외

@Slf4j
public class CheckedTest {

    @Test
    void checked_catch() {
        Service service = new Service();
        service.callCatch();
    }

    @Test
    void checked_throw() {
        Service service = new Service();
        assertThatThrownBy(() -> service.callThrow())
                .isInstanceOf(MyCheckedException.class);
    }

    /**
     * Exception을 상속받은 예외는 체크 예외가 된다.
     */
    static class MyCheckedException extends Exception {
        public MyCheckedException(String message) {
            super(message);
        }
    }

    /**
     * Checked 예외는
     * 예외를 잡아서 처리하거나, 던기저나 둘중 하나는 필수로 선택해야 한다.
     */
    static class Service {
        Repository repository = new Repository();

        /**
         * 예외를 잡아서 처리하는 코드
         */
        public void callCatch() {
            try {
                repository.call();
            } catch (MyCheckedException e) {
                //예외 처리 로직
                log.info("예외 처리, message={}", e.getMessage(), e);
            }
        }

        /**
         * 체크 예외를 밖으로 던지는 코드
         * 에크 예외는 예외를 잡지 않고 밖으로 던지려면 throws 예외를 메서드에 필수로 선언해야 한다.
         * @throws MyCheckedException
         */
        public void callThrow() throws MyCheckedException {
            repository.call();
        }
    }

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

체크 예외는 잡아서 처리할 수 없을 때, 예외를 밖으로 던지는 throws 예외를 필수로 선언해야 한다. 그렇지 않으면 컴파일 오류가 발생한다. 이는 개발자가 실수로 예외를 누락하지 않도록 해주는 안전장치이지만 실제로는 개발자가 모든 체크 예외를 반드시 잡거나 던지도록 처리해야 하기 때문에 번거롭다. 또한 반드시 잡거나 던져야 하므로 해당 클래스의 로직과 관련 없는 의존 관계를 추가해야 하는 문제도 있다.

예를 들어 Repository에서 DB에 관한 로직을 처리했을 때 체크 예외인 SQLException이 발생하면 Service(비즈니스 로직 처리)는 이를 잡거나 던져야 한다. 이로 인해 비즈니스 로직과는 상관없는 예외를 선언해야 한다. SQLException처럼 데이터베이스에서 발생하는 문제들은 대부분 애플리케이션 로직에서 처리할 방법이 없다.

Repository를 JDBC 기술이 아닌 JPA와 같은 다른 기술로 변경하여 예외가 변경된다고 하자. SQLException에 의존하던 모든 Service, Controller의 코드를 JPAException에 의존하도록 고쳐야 한다. Service나 Controller 입장에서는 처리할 수 도 없는 예외를 의존해야 하는 큰 단점이 발생한다. 결과적으로 OCP, DI를 통해 클라이언트 코드의 변경 없이 대상 구현체를 변경할 수 있다는 장점이 체크 예외로 인해 발목을 잡게 된다.

 

throws Exception

SQLException, ConnectionException과 같은 시스템 예외는 Controller나 Service에서는 대부분 복구가 불가능하고 처리할 수 없는 체크 예외이다. 따라서 throws로 처리해주어야 한다. 최상위 예외인 Exception을 던져도 문제를 해결할 수 있다. 

이렇게 하면 Exception을 포함한 하위 타입인 SQLException, ConnectionException도 함께 던지게 된다. 코드는 깔끔해지는 것 같지만 Exception은 최상위 타입이므로 모든 체크 예외를 다 밖으로 던지는 문제가 발생한다. 중간에 중요한 체크 예외가 발생해도 컴파일러는 문법에 맞다고 판단하여 컴파일 오류가 발생하지 않는다. 이렇게 Exception 자체를 밖으로 던지는 것은 좋지 않은 방법이다.

 

언체크 예외

언체크 예외는 말 그대로 컴파일러가 예외를 체크하지 않는다는 뜻이다. 체크 예외와 다른 점은 예외를 던지는 throws를 생략할 수 있다. 이 경우 자동으로 예외를 던진다. 

@Slf4j
public class UncheckedTest {

    @Test
    void unchecked_catch() {
        Service service = new Service();
        assertThatThrownBy(() -> service.callThrow())
                .isInstanceOf(MyUncheckedException.class);
    }

    @Test
    void unchecked_throw() {
        Service service = new Service();
        service.callThrow();
    }

    /**
     * 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 new MyUncheckedException("ex");
        }
    }
}

언체크 예외는 주로 생략하지만, 중요한 예외의 경우 선언해두면 해당 코드를 호출하는 개발자가 이런 예외가 발생한다는 점을 IDE를 통해 좀 더 편리하게 인지할 수 있다.

언체크 예외는 throws를 생략할 수 있으므로 신경 쓰고 싶지 않은 예외의 의존관계를 참조하지 않아도 된다. 하지만 컴파일러가 잡아주지 않으므로 개발자가 실수로 예외를 누락할 수 있다.

 

예외 전환

체크 예외를 언체크 예외로 변환하는 방법으로 Service, Controller는 해당 예외를 처리할 수 없다면 별도의 선언을 하지 않아도 된다.

@Slf4j
public class UncheckedAppTest {

    @Test
    void unchecked() {
        Controller controller = new Controller();
        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 message) {
            super(message);
        }
    }

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

Repository에서 체크 예외인 SQLException이 발생하면 런타임 예외인 RuntimeSQLException으로 전환해서 예외를 던진다.  이때 기존 예외를 포함해주어야 예외 출력 시 스택 트레이스에서 기존 예외도 함께 확인할 수 있다.

시스템에서 발생하는 예외는 대부분 복구가 불가능한 예외이다. 런타임 예외를 사용하면 Service나 이런 복구 불가능한 예외를 신경 쓰지 않아도 된다. 또한 런타임 예외는 해당 객체가 처리할 수 없는 예외는 무시하면 된다. 체크 예외처럼 강제로 의존하지 않아도 된다. 이렇게 런타임 예외를 사용하면 중간에 기술이 변경되어도 해당 예외를 사용하지 않는 Controller, Service에서는 코드를 변경하지 않아도 된다.

 

Summary

• 기본적으로 언체크(런타임) 예외를 사용하자
  • 체크 예외를 언체크 예외로 변환할 때는 기존 예외를 포함해야 한다.
• 체크 예외는 비즈니스 로직상 의도적으로 던지는 예외에만 사용하자.
  • 이 경우 해당 예외를 잡아서 반드시 처리해야 하는 문제일 때만 사용한다.