5-5. 체크 예외 활용

# 기본 원칙

 

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

 

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

  - 해당 예외를 잡아서 반드시 처리해야 하는 문제 일때만 (계좌 이체 실패 예외, 결제시 포인트 부족 예외)

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

  -  이 경우에도 런타임예외로 작성 후 메뉴얼에 작성해 두는 방법도 있다.

 

 

 

 

 

 

 

 

 

# 체크 예외의 문제점

 

 

 

1. 서비스는 리포지토리와 NetworkClient 를 둘 다 호출한다.

 

2. 그런데 서비스는 이 둘을 처리할 방법을 모른다. ConnectException처럼 연결이 실패하거나, SQLException 처럼 데이터베이스에서 발생하는 문제 처럼 심각한 문제들은 대부분 애플리케이션 로직에서 처리 할 방법이 없다.

 

3. 서비스는 처리 할 수 없으므로 throws SQLException, ConnectionException 으로 밖으로 던진다.

 

4. 컨트롤러에서도 처리 할 방법이 없어 밖으로 던진다.

 

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

 

6. API라면 보통 500 에러 응답해준다.

 

 

 

 

 

 

 

 

 

 

# CheckAppTest

 

 

# 2가지문제

 

1. 복구 불가능한 문제

 

SQLException을 예를 들면 데이터베이스에 무언가 문제가 있어서 발생하는 예외이다. SQL 문법에 문제가 있을 수 도 있고, 데이터베이스 자체에 뭔가 문제가 발생했을 수 도있다. 데이터베이스 서버가 중간에 다운되었을 수 도 있다. 이런 문제들은 대부분 복구가 불가능하다. 특히나 대부분의 서비스나 컨트롤러는 이런 문제를 해결할 수 는 없다. 따라서 이런 문제들은 일관성있게 공통으로 처리해야 한다. 오류로그를 남기고 개발자가 해당 오류를 빠르게 인지하는 것이 필요하다. 서블릿필터, 스프링인터셉터, 스프링의 ControllerAdvice를 사용하면 이런 부분을 깔끔하게 공통으로 해결 할 수 있다.

 

 

2. 의존 관계에 대한 문제

체크예외의 또 다른 심각한 문제는 예외에 대한 의존관계 문제이다.
앞서 대부분의 예외는복구 불가능한 예외라고 했다. 그런데 체크예외 이기 때문에 컨트롤러나 서비스 입장에서는 본인이 처리할 수 없어도 어쩔 수 없이 throws를 통해 던지는 예외를 선언해야한다.

 

(서비스, 컨트롤러에서 SQLException에 의존하게 된다. = JDBC기술에 의존하게 된다. = 향후 JPA로 변경 시 다른 예외로 올라오기 때문에 서비스, 컨트롤러의 코드를 모두 고쳐야한다.)

-> OCP, DIP 위반

 

-> 그렇다고 throws Exception 하면 어떨까.. 모든 체크 예외를 다 잡기 때문에 안티패턴이 된다.

 

 

 

 

 

 

 

 

# 정리

 

 

처리할 수 있는 체크예외라면 서비스나 컨트롤러에서 처리하겠지만, 지금처럼 데이터베이스나 네트워크 통신처럼 시스템레벨에서 올라온 예외들은 대부분 복구가 불가능하다. 그리고 실무에서 발생하는 대부분의 예외들은 이런 시스템예외들이다.

 

-> 런타임예외를 활용하자.

 

 

 

 

꾸준히 다시보자.

 

1. 221014

2. 221101