[스프링 DB 1편] - 13. 체크 예외와 언체크(런타임) 예외 활용

 

체크 예외 활용

 

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

1. 기본적으로 언체크(런타임) 예외를 사용하자.

2. 체크 예외는 비즈니스 로직상 의도적으로 던지는 예외에만 사용하자.

 

이 경우 해당 예외를 잡아서 반드시 처리해야 하는 문제일 때만 체크 예외를 사용해야 한다.

 

 

예를 들어서 다음과 같은 경우가 있다.

체크 예외 예)

• 계좌 이체 실패 예외
  결제시 포인트 부족 예외
• 로그인 ID, PW 불일치 예외

 

물론 이 경우에도 100% 체크 예외로 만들어야 하는 것은 아니다.

 

다만 계좌 이체 실패처럼 매우 심각한 문제는 개발자가 실수로 예외를 놓치면 안된다고 판단할 수 있다.

 

이 경우 체크 예외로 만들어 두면 컴파일러를 통해 놓친 예외를 인지할 수 있다.

 

 

 

 

체크 예외의 문제점

 

체크 예외는 컴파일러가 예외 누락을 체크해주기 때문에 개발자가 실수로 예외를 놓치는 것을 막아준다.

 

체크 예외가 런타임 예외보다 더 안전하고 좋아보이는데, 왜 체크 예외를 기본으로 사용하는 것이 문제가 될까?

 

 

SQLException , ConnectException 예외 발생

 

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

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

 

두 곳에서 올라오는 체크 예외인 SQLException 과 ConnectException 을 처리해야 한다.

 

 

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

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

 

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

 

 

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

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

 

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

 

 

웹 애플리케이션이라면 서블릿의 오류 페이지나,

 

또는 스프링 MVC가 제공하는 ControllerAdvice 에서 이런 예외를 공통으로 처리한다.

 

 

 

 

지금까지 설명한 예시와 코드를 보면 크게 2가지 문제를 알 수 있다.

 

1.  복구 불가능한 예외

 

대부분의 예외는 복구가 불가능하다. 일부 복구가 가능한 예외도 있지만 아주 적다.

 

따라서 이런 문제들은 일관성 있게 공통으로 처리해야 한다

 

스프링의 ControllerAdvice 를 사용하면 이런 부분을 깔끔하게 공통으로 해결할 수 있다.

 

 

2.  의존 관계에 대한 문제

 

체크 예외의 또 다른 심각한 문제는 예외에 대한 의존 관계 문제이다.

 

 

JDBC -> JPA 변경시 문제점

 

 

서비스, 컨트롤러에서 java.sql.SQLException 을 의존

 

향후 리포지토리를 JDBC 기술이 아닌 다른 기술로 변경한다면 예외도 함께 변경해야한다.

SQLException 에 의존하던 모든 서비스, 컨트롤러의 코드를 JPAException 에 의존하도록 고쳐야 한다.

 

 

 

언체크 예외 활용

 

RuntimeSQLException , RuntimeConnectException 예외 발생

 

 

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

 

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

 

 

public void runSQL() throws SQLException {
    throw new SQLException("ex");
}

 

리포지토리에서 체크 예외인 SQLException 이 발생

 

 

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

 

런타임 예외인 RuntimeSQLException 으로 전환해서 예외를 던진다.

 

 

 

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

 

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

 

 

런타임 예외이기 때문에 컨트롤러나 서비스가 예외를 처리할 수 없다면  

 

 throws RuntimeSQLException, RuntimeConnectException  생략할 수 있다.

 

따라서 컨트롤러와 서비스에서 해당 예외에 대한 의존 관계가 발생하지 않는다.

 

 

 

JDBC -> JPA 변경 가능

 

 

런타임 예외를 사용하면 중간에 기술이 변경되어도

 

해당 예외를 사용하지 않는 컨트롤러, 서비스에서는 코드를 변경하지 않아도 된다.

 

구현 기술이 변경되는 경우, 예외를 공통으로 처리하는 곳에서는 예외에 따른 다른 처리가 필요할 수 있다.

 

하지만 공통 처리하는 한곳만 변경하면 되기 때문에 변경의 영향 범위는 최소화 된다.

 

 

 

정리

 

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

 

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

 

런타임 예외도 throws 에 선언할 수 있다. 

 

물론 컨트롤러나 서비스에서 RuntimeException을 사용하지 않는다면 무시해도 된다.

 

 

 

예외 포함과 스택 트레이스

 

예외를 전환할 때는 꼭! 기존 예외를 포함해야 한다.

 

그렇지 않으면 스택 트레이스를 확인할 때 심각한 문제가 발생한다.

 

 

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

 

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

 

 

cf) 스택 트레이스(stack trace) 

 

스택 트레이스(stack trace)는 프로그램에서 예외(exception)가 발생했을 때,

 

해당 예외가 발생한 지점부터 호출된 메소드들의 호출 스택(call stack) 정보를 출력하는 것을 말합니다.

 

일반적으로, 예외가 발생하면 해당 예외를 처리할 catch 문이 있는 곳으로 예외가 전달됩니다.

 

이때 예외를 처리하는 메소드의 호출 스택과 함께 예외 객체에 대한 정보가 출력됩니다.

 

스택 트레이스는 프로그램의 디버깅이나 예외 처리에 유용합니다.

 

예외가 발생한 지점과 호출된 메소드들의 정보를 제공하여, 예외가 발생한 원인을 파악하는데 도움이 됩니다.

 

또한, 스택 트레이스를 로그에 남겨두면, 프로그램 사용자들이 발생한 예외를 보고 개발자에게 보고하기 쉬워지기도 합니다.

 

 

기존 예외를 포함하는 경우

public void call() {
    try {
        runSQL();
    } catch (SQLException e) {
        throw new RuntimeSQLException(e); // 기존 예외(e) 포함
    }
}

 

 

 

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

 

 

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

public void call() {
    try {
        runSQL();
    } catch (SQLException e) {
        throw new RuntimeSQLException(); // 기존 예외(e) 제외
    }
}

 

 

 

예외를 포함하지 않아서 기존에 발생한 java.sql.SQLException 과 스택 트레이스를 확인할 수 없다.

 

변환한 RuntimeSQLException 부터 예외를 확인할 수 있다.

 

만약 실제 DB에 연동했다면 DB에서 발생한 예외를 확인할 수 없는 심각한 문제가 발생한다.

 

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

 

 

 

 

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-db-1/dashboard

스프링 DB 1편 - 데이터 접근 핵심 원리 - 인프런 | 강의