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

[YuDeokRin]

4️⃣ 언체크 예외 기본 이해

• RuntimeException과 그 하위 예외는 언체크 예외로 분류된다.
• 언체크 예외는 말 그대로 컴파일러가 예외를 체크하지 않는다는 뜻이다.
• 언체크 예외는 체크 예외와 기본적으로 동일하다. 차이가 있다면 예외를 던지는 throws를 선언하지 않고, 생략
• 할 수 있다. 이 경우 자동으로 예외를 던진다.

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

• UncheckedTest

@Slf4j
public class UncheckedTest {

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

    }

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

    /**
     * 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");
        }
    }

}

✅ 언체크 예외를 잡아서 처리하는 코드

• 언체크 예외도 필요한 경우 이렇게 잡아서 처리할 수 있다.

try {
		repository.call();
} catch (MyUncheckedException e) {
		//예외 처리 로직
	  log.info("예외처리, message={}", e.getMessage(), e);
}

✅ 언체크 예외를 밖으로 던지는 코드 - 생략

• 언체크 예외는 체크예외와 다르게 throws 예외를 선언하지 않아도된다.
• 이유는 컴파일러가 이런 부분을 체크하지 않기 때문에 언체크 예외이다.

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

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

• “throws 예외” 부분을 생략해도된다.
• 언체크 예외는 주로 생략한다.
• 중요한 예외의 경우 선언을 하는데 아래와 같이 하면 인지하기 더 좋다.

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

▶️ 언체크 예외의 장단점

• 언체크 예외는 예외를 잡아서 처리할 수 없을 때, 예외를 밖으로 던지는 throws 예외를 생략할 수 있다.
• 장점
  • 신경쓰고 싶지 않은 언체크 예외를 무시할 수 있다.
  • 체크 예외의 경우 처리할 수 없는 예외를 밖으로 던지려면 항상 throws 예외를 선언해야 하지만, 언체크 예외는 이 부분을 생략할 수 있다.
  • 신경쓰고 싶지 않은 예외의 의존관계를 참조하지 않아도 되는 장점
• 단점
  • 언체크 예외는 개발자 실수로 예외를 누락할 수 있다. 반면에 체크 예외는 컴파일러를 통해 예외 누락을 잡아준다.

5️⃣ 체크 예외 활용

• 체크 예외는 언제사용하고 언체크 예외를 언제 사용하면 좋을까 ?

✅ 기본 원칙 2가지

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

✅ 체크 예외의 문제점

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

• 누락하지 않게 명시적으로 예외를 잡아서 처리하거나, 처리할 수 없을 때는 예외를 던지도록 method() throws 예외로 선언해야 한다.

• 체크 예외 문제점 - 그림

  • 리포지토리는 DB에 접근해서 데이터를 저장하고 관리한다. 여기서는 SQLException 체크 예외를 던진다.
  • NewworkClient는 외부 네트워크에 접속해서 어떤 기능을 처리하는 객체이다. 여기서는 ConnectionException 체크 예외를 던진다.
  • 서비스는 리포지토리와 NetworkClient를 둘다 호출한다.
    • 따라서 두 곳에서 올라오는 체크 예외인 SQLException과 ConnectionException을 처리해야 한다.
    • 그런데 서비스느 이 둘을 처리할 방법을 모른다. ConnectionException처럼 연결이 실패하거나, SQLException 처럼 데이터베이스에서 발행하는 문제처럼 심각한 문제들은 대부분 애플리케이션 로직에서 처리할 방법이 없다.
    • 서비스는 SQLException과 ConnectionException를 처리할 수 없으므로 둘다 밖으로 던진다.
      • 체크 예외이기 때문에 던질 경우 다음과 같이 선언해야 한다.
      • method() throws SQLException, ConnectionExcpetion
    • 컨트롤러도 두 예외를 처리할 방법 X
      • method() throws SQLException, ConnectionExcpetion를 선언해서 예외를 밖으로 던진다.
    • 웹애플리케이션이라면 서블릿의 오류 페이지나, 또는 스프링 MVC가 제공하는 ControllerAdvice에서 이런 예외를 공통으로 처리한다.
      • 이런 문제들은 보통 사용자에게 어떤 문제가 발생했는지 자세히 설명하기가 어렵다. 그래서 사용자에게는
      • "서비스에 문제가 있습니다." 라는 일반적인 메시지를 보여준다. ("데이터베이스에 어떤 오류가 발생했어요"
        라고 알려주어도 일반 사용자가 이해할 수 없다. 그리고 보안에도 문제가 될 수 있다.)
        API라면 보통 HTTP 상태코드 500(내부 서버 오류)을 사용해서 응답을 내려준다.
      • 이렇게 해결이 불가능한 공통 예외는 별도의 오류 로그를 남기고, 개발자가 오류를 빨리 인지할 수 있도록 메일, 알림(문자, 슬랙)등을 통해서 전달 받아야 한다. 예를 들어서 SQLException 이 잘못된 SQL을 작성
        해서 발생했다면, 개발자가 해당 SQL을 수정해서 배포하기 전까지 사용자는 같은 문제를 겪게 된다.

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

@Slf4j
public class CheckedAppTest {

    @Test
    void checked() {
        Controller controller = new Controller();

    }

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

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

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

        public void logic() throws SQLException, ConnectionException{
            repository.call();
            networkClientl.call();
        }
    }

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

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

}

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

✅ 2가지 문제

1. 복구 불가능한 예외

2. 의존관계에 대한 문제

3. 복구 불가능한 예외

• 대부분의 예외는 복구가 불가능하다. (일부 복구가 가능한 예외도 있음)
• SQLException은 데이터베이스에 문제가 있어서 발생하는 예외이다.
  • SQL문법 문제 , 데이터베이스 자체 문제 …등
  • 복구가 불가능하다.
• 서블릿 필터, 스프링 인터셉터, 스프링의 ControllerAdvice를 사용하면 이런 부분을 깔끔하게 공통으로 해결할 수 있다.

1. 의존 관계에 대한 문제

• 체크 예외의 문제는 예외에 의존 관계 문제이다.
• 예외는 복구 불가능한 예외라고 했다. 하지만 체크 예외이기 때문에 컨트롤러나 서비스 입장에서는 본인이 처리할 수 없어도 어쩔 수 없이 throws를 통해 던지는 예외를 선언해야 한다.

✅ 체크 예외 throws 선언

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

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

• throws SQLException, ConnectException처럼 예외를 던지는 부분을 코드에 선언하는 것이 왜 문제가 될까? → 서비스, 컨트롤러에서 java.sql.SQLException을 의존하기 때문에 문제가 됨

• 향후 리포지토리를 JDBC 기술이 아닌 다른 기술로 변경한다면, 그래서 SQLException이 아니라 JPAException 으로 예외가 변경된다면 어떻게 될까?

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

• 서비스나 컨트롤러 입장에서는 본인이 처리할 수도 없는 예외를 의존해야 한다는 단점이 생긴다.

• OCP, DI를 통해 클라이언트 코드의 변경 없이 대상 구현체를 변경할 수 있다는 장점이 체크 예외 때문에 발목을 잡게 됨

• JDBC JPA 같은 기술로 변경하면 예외도 함께 변경해야한다. 그리고 해당 예외를 던지는 모든 다음 부분도 함 께 변경해야 한다.
  • logic() throws SQLException → logic() throws JPAException
  • (참고로 JPA 예외는 실제 이렇지는 않고, 이해하기 쉽게 예를 든 것이다.)

6️⃣ 언체크 예외 활용

✅ 런타임 예외 사용 - 그림

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

@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);
						} 
		}
		
    private void runSQL() throws SQLException {
        throw new SQLException("ex");
		} 
}
     

✅ 예외 전환

• 리포지토리에서 체크 예외인 SQLException이 발생하면 런타임 예외인 RuntimeSQLException으로 전환해서 예외를 던진다.
  • 참고로 이때 기존 예외를 포함해주어야 예외 출력시 스택 트레이스에서 기존 예외도 함께 확인할 수 있다.
• NetworkClient는 단순히 기존 체크 예외를RuntimeConnectException` 이라는 런타임 예외가 발생하
  도록 코드를 바꾸었다.

✅ 런타임 예외 - 대부분 복구 불가능한 예외

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

✅ 런타임 예외 - 의존 관계에 대한 문제

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

• 런타임 예외 throws 생략

class Controller {
     public void request() {
         service.logic();
     }
}
 class Service {
     public void logic() {
	       repository.call();
         networkClient.call();
     }
}

• 런타임 예외이기 때문에 컨트롤러나 서비스가 예외를 처리할 수 없다면 다음 부분을 생략할 수 있다.
  • method() throws RuntimeSQLException, RuntimeConnectException
  • 따라서 컨트롤러와 서비스에서 해당 예외에 대한 의존 관계가 발생하지 않는다.

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

▶️ 런타임 예외는 문서화

• 런타임 예외는 문서화를 잘 해놔야한다.

• 코드에 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);

• Spring 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;

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

• 예외를 전환할 때는 기존 예외를 포함해야한다
• 포함 안할 경우 스택 트레이스를 확인할 때 심각한 문제를 발생한다.

@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); //기존 예외(e) 포함 }
}

• java.sql.SQLException과 스택 트레이스를 확인

13:10:45.626 [Test worker] INFO hello.jdbc.exception.basic.UncheckedAppTest - ex
 hello.jdbc.exception.basic.UncheckedAppTest$RuntimeSQLException:
 java.sql.SQLException: ex
     at
 hello.jdbc.exception.basic.UncheckedAppTest$Repository.call(UncheckedAppTest.jav
 a:61)
     at
 hello.jdbc.exception.basic.UncheckedAppTest$Service.logic(UncheckedAppTest.java:
 45)
     at
 hello.jdbc.exception.basic.UncheckedAppTest$Controller.request(UncheckedAppTest.java:35) at
 hello.jdbc.exception.basic.UncheckedAppTest.printEx(UncheckedAppTest.java:24)
  Caused by: java.sql.SQLException: ex at
 hello.jdbc.exception.basic.UncheckedAppTest$Repository.runSQL(UncheckedAppTest.j
 ava:66)
at
 hello.jdbc.exception.basic.UncheckedAppTest$Repository.call(UncheckedAppTest.jav
a:59)

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

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

[Test worker] INFO hello.jdbc.exception.basic.UncheckedAppTest - ex
 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에서 발생한 예외를 확인할 수 없는 심각한 문제가 발생한다.

🔗 출처

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