예외 계층

• Object: 예외도 객체이다. 머든 객체의 최상위 부모가 Object이므로 예외의 최상위 부모도Object이다
• Throwable: 최상위 예외이다. 하위에 Exception,Error가 있다
• Error: 메모리 부족이나 심각한 시스템 오류와 같이 에플리케이션에서 복구 불가능한 시스템 예외이다.
• Exception: 체크 예외
  • 에플리케이션 로직에서 사용할 수 있는 실질적인 최상위 예외이다
  • Exception과 그 하위 예외는 모두 컴파일러가 체크하는 체크 예외이다. 단 RuntimeException은 이에 해당하지 않는다
• RuntimeException: 언체크 예외, 런타임 예외
  • 컴파일러가 체크하지 않는 예외이다
  • RuntimeException과 그 자식 예외는 모두 언체크 예외이다
  • RuntimeException의 이름을 따라서 RuntimeException과 그 하위 언체크 예외를 런타임 예외라고 부른다

기본예외

예외에서는 2가지 규칙을 기억하자

• 예외는 잡아서 처리하거나 던져야 한다

• 예외를 잡거나 던질 때 지정한 예외뿐만 아니라 그 예외의 자식들도 함께 처리된다

  • 예를들어 Exception을 catch로 잡으면 그 하위 예외들도 모두 잡을 수 있다

• 자바 main() 스레드의 경우 예외 로그를 출력하면서 시스템이 종료

• 웹 애플리케이션의 경우 여러 사용자의 요청을 처리하기 때문에 하나의 예외 때문에 시스템이 종료되면 안된다. WAS가 해당 예외를 받아서 처리하는데, 주로 사용자에게 개발자가 지정한, 오류 페이지를 보여준다

체크 예외 기본 이해

• Exception과 그 하위 예외는 모두 컴파일러가 체크하는 체크예외이며 이때 RuntimeException은 예외로 한다
• 체크예외는 잡아서 처리하거나 밖으로 던지도록 선언해야한다. 그러지 않으면 컴파일러에서 오류가 발생한다

체크 예외 코드

@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);
          }
	}
    
     static class Service {
          Repository repository = new Repository();
/**
* 예외를 잡아서 처리하는 코드 */
      public void callCatch() {
              try {
                  repository.call();
              } catch (MyCheckedException e) {
//예외 처리 로직
				log.info("예외 처리, message={}", e.getMessage(), e); }
			 }	
	  public void callThrow() throws MyCheckedException {
              repository.call();
			} 
	}
      static class Repository {
          public void call() throws MyCheckedException {
              throw new MyCheckedException("ex");
          }
	} 
}

Exception을 상속받은 예외

  static class MyCheckedException extends Exception {
      public MyCheckedException(String message) {
          super(message);
      }
  }

• MyCheckedException는 Exception을 상속받았다. Exception을 상속받으면 체크예외가 됨
• RuntimeException을 상속 받으면 언체크 예외가 됨

try~catch 예외처리

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

• service.callCatch() 에서 예외를 처리했기 때문에 테스트 메서드까지 예외가 올라오지 않는다

public void callCatch() {
      try {
          repository.call();
      } catch (Exception e) {
		//예외 처리 로직 
      }
}

• catch에 MyCheckedException의 상위 타입인 Exception을 적어도 MyCheckedException을 잡을 수 있다
• catch에 예외를 지정하면 해당 예외와 그 하위 타입 예외를 모두 잡아줌
• throws로 예외를 밖으로 던져버리는 전략도 물론 사용가능하다

체크예외의 장단점

체크 예외는 잡아서 처리할수 없을 때 예외를 밖으로 던지는 throws예외를 필수로 선언해야 함. 그렇지 않으면 컴파일 오류가 발생해 장단점이 동시에 존재한다

언체크 예외 기본 이해

• 언체크 예외는 기본적으로 컴파일러가 체크하지 않는다
• 언체크 예외는 기본적으로 체크 예외와 동일하지만 차이가 있다면, throws를 선언하지 않고 생략이 가능하다는 점이다

언체크 예외

 static class MyUncheckedException extends RuntimeException {
        public MyUncheckedException(String message) {
            super(message);
        }
}

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

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

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

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

• 언체크 예외는 말그대로 컴파일러가 체크하지않는 예외이기 때문에 throws 선언을 하지 않아도 됨

언체크 예외 장단점

장점: throws 생략
단점: 컴파일러가 체크를 하지 않아 개발자가 누락할 가능성이 있음

체크예외 활용

기본원칙 2가지

• 기본적으로 런타임 예외를 사용
• 체크 예외는 비즈니스 로직상 의도적으로 던지는 예외에만 사용
  • 이 경우 해당 예외를 잡아서 반드시 처리해야하는 문제일때만 사용해야 함
    • ex) 계좌이체 실패 예외
    • 결제시 포인트 부족 실패 예외

체크예외의 문제점

• 복구 불가능한 예외

  • 대부분의 예외는 복구가 불가능하다. SQLException로 예를 들자면 데이터베이스에 문제가 있어서 발생하는 예외이다. sql상 문법 오류 또는 데이터베이스 서버 다운등의 문제가 발생했을 수 있다. 이런 문제들은 대부분 복구가 불가능하다. 또한 대부분의 서비스나 컨트롤러는 이런 문제를 해결할 수 없다. 따라서 이런 문제들은 일관성있게 공통으로 처리해야 한다. 서블릿 필터, 스프링 인터셉터, 스프링의 ControllerAdvice 를 사용하면 이런 부분을 깔끔하게 공통으로 해결할 수 있다

• 의존관계에 대한 문제

  • 체크 예외의 심각한 문제는 예외에 대한 의존 문제이다. 체크 예외는 대부분 해결 불가능한 오류이므로 throws로 던지면 서비스, 컨트롤러 , 레포지토리들도 해당 예외를 모두 알아야한다. 그래서 불필요한 의존관계가 발생하게된다

• 이런 문제가 발생하는 걸 막기 위해 throw Exception을 쓸수도 있는데 이는 위험한 결정이다.
  사용자가 의도한 모든 오류를 던지기 때문에 어떤 오류가 발생했는지 모르게 될 가능성이 크다

언체크 예외 활용

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

예외 전환

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

복구 불가능한 문제

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

의존관계 처리

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

기존예외를 포함

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

		throw new RuntimeSQLException(e); 
        //기존 예외(e) 포함 
      }
}

기존예외 포함 x

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

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