Spring
예외 계층
자바는 기본적으로 아래의 그림과 같은 예외 계층을 갖는다.
- Object : 예외도 객체이므로 모든 객체의 최상위 부모는 Object이므로 예외의 최상위 부모도 Object이다.
- Throwable : 최상위 예외이다. 하위에 Exception과 Error가 있다
- Error : 메모리부족이나 심각한 시스템 오류와 같이 애플리케이션이 복구 불가능한 시스템 예외이다. 애플리케이션 개발자는 이 예외를 잡으려고해서는 안된다.
- 상위 예를 catch로 잡으면 그 하위 예외까지 함께 잡는다. 따라서 애플리케이션 로직에서는 Throwable 예외도 잡으면 안되는데, 앞서 이야기한 Error 예외도 함께 잡을 수 있기 때문이다. 애플리케이션 로직은 이러한 이유로 Exception 부터 필요한 예외로 생각하고 잡으면 된다.- Error도 언체크예외이다.
- Exception : 체크 예외
- 애플리케이션 로직에서는 사용할 수 있는 실질적인 최상위 예외이다.- Exception과 그 하위 예외는 모두 컴파일러가 체크하는 체크 예외이다. 단, RuntimeException은 예외로 한다.
- RuntimeException : 언체크 예외, 런타임 예외
- 컴파일러가 체크하지 않는 언체크 예외이다.- RuntimeException과 그자식 예외는 모두 언체크 예외이다.
- RuntimeException의 이름을 따라서 RuntimeException과 그 하위 예외를 런타임 예외라고 많이 부른다.
예외 기본 규칙
예외는 기본적으로 아래의 2가지를 기본 규칙으로 한다.
1. 예외는 잡아서 처리하거나 던져야한다.
2. 예를 잡거나 던질 때 지정한 예외 뿐만 아니라 그 예외이 자식들도 함께 처리된다.
체크 예외
Exception과 그 하위 예외는 모두 컴파일러가 체크하는 체크 예외이다. 단 RuntimeException은 언체크 예외이다.
체크 예외는 잡아서 처리하거나 또는 밖으로 던지도록 선언해야한다. 그렇지 않으면 컴파일러 오류가 발생한다.
(체크 예외는 말그대로 컴파일러가 예외를 체크한다는 의미로 해석될것같다.
즉, 컴파일러가 예외의 기본 규칙을 체크한다. 예외의 기본 규칙은 잡아서 처리하거나 던져야하므로 소스 코드에서 예외의 기본 규칙이 지켜져있지 않다면 컴파일 오류가 발생한다.)
아래의 코드는 체크 예외의 예시 코드이다.
@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");
}
}위 예시에서 보면 Exception을 상속받은 예외 클래스를 정의했다. 따라서 MyCheckedException은 체크 예외가 된다. Repository 클래스에서 아래의 코드를 통해서 예외를 발생시킨다.
static class Repository {
public void call() throws MyCheckedException {
throw new MyCheckedException("ex");
}
}체크 예외가 발생했을때 예외 처리 규칙에 따라서 던지거나 잡아서 처리해야하므로 throws를 선언해줘야한다. 그렇지 않으면 컴파일 에러가 발생한다.
주의)
throws Exception과 Catch(Exception)은 매우 안좋은 습관이다. 왜냐하면 모든 예외를 잡고 던진다는 의미가 되기 떄문이다. 모든 예외를 다 잡고 던지면 안되는 이유는 꼭 잡아야하느 예외도 던지게 만들게 되기 떄문이다.
꼭 잡아야하는 예외도 던지게 되면 다른 계층에서 알 필요가 없는 예외가 서비스 계층, 컨트롤 계층까지 넘어오게 된다.
체크 예외의 장단점
체크 예외는 예외를 잡아서 처리할 수 없을떄, 예외를 밖으로 던지는 'throws 예외' 를 필수로 선언해줘야 한다. 그렇지 않으면 컴파일 오류가 발생한다. 이것 떄문에 장점과 단점이 동시에 존재한다.
- 장점 : 개발자가 실수로 예외를 누락하지 않도록 컴파일러를 통해 문제를 잡아주는 훌륭한 안전장치이다.
- 단점 : 하지만 실제로는 개발자가 모든 체크 예외를 반드시 잡거나 던지도록 처리해야하기 떄문에 너무 번거로운 일이 된다. 크게 신경 쓰고 싶지 않은 예외까지 모두 챙겨야한다 추가로 의존관계에 따른 단점도 존재한다.
언체크 예외
RuntimeException과 그 하위 예외는 언체크예외로 분류된다.
언체크 예외는 말그대로 컴파일러가 예외를 체크하지 않는다는 뜻이다.
언체크 예외는 체크 예외와 기본적으로 동일하다. 차이가 있다면 예외를 던지는 throws를 선언하지 않고 생략할 수 있다. 이 경우 자동으로 예외를 던진다.
체크 예외 vs 언체크 예외
- 체크 예외 : 예외를 잡아서 처리하지 않으면 항상 throws에 던지는 예외를 선언해야한다.
- 언체크 예외 : 예외를 잡아서 처리하지 않아도 throws를 생략할 수 있다.
아래는 체크 예외의 예시 코드 이다.
@Test
void unchecked_catch() {
Service service = new Service();
service.callCatch();
}
@Test
void unchecked_throw() {
Service service = new Service();
assertThatThrownBy(() -> service.callThrow())
.isInstanceOf(MyUncheckedException.class);
}
/**
* 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");
}
}언체크 예외는 체크 예외와 달리 'throws 예외' 를 선언하지 않아도 된다.
public void call() {
throw new MyUncheckedException("ex");
}말그대로 컴파일러가 이런 부분을 체크하지 않기 떄문에 언체크 예외이다.
참고로 언체크 예외도 'throws 예외' 를 선언해도 된다.(물론 생략도된다.)
언체크예외는 주로 생략하지만 중요한 예외의 경우 이렇게 선언해두면 해당 코드를 호출하는 개발자가 이런 예외가 발생한다는 점을 IDE를 통해 좀 더 편리하게 인지할 수 있다. (컴파일 시점에 막을 수 있는것은 아니고, IDE를 통해서 인지할 수 있을 정도이다)
언체크 예외의 장단점
언체크 예외는 예외를 잡아서 처리할 수 없을떄 예외를 밖으로 던지는 'throws 예외' 를 생략할 수 있다.
- 장점 : 신경쓰고싶지 않은 언체크 예외를 무시할 수 있다. 체크 예외의 경우 처리할수 없는 예외를 밖으로 던지려면 항상 throws 예외 코드를 선언해야하지만 언체크예외는 이 부분을 생략할 수 있다. 따라서 의존관계도 맺어지지 않는다.
- 단점 : 언체크 예외는 개발자가 실수로 예외를 누락할 수 있다. 반면에 체크 예외는 컴파일러를 통해 예외 누락을 잡아준다.
체크 예외 활용
예외에 대한 기본 원칙은 아래와 같다.
- 기본적으로 언체크(런타임)예외를 사용한다.
- 체크 예외는 비지니스 로직상 의도적으로 던지는 예외에만 사용한다.
- 이 경우 해당 예외를 잡아서 반드시 처리해야하는 문제일때만 체크 예외를 사용해야한다.- 물론 이 경우도 100% 체크예외로 하지 않아도 된다.
참고)
최근 체크 예외는 사용하지 않는게 트랜드이다. 보통은 언체크예외를 많이 사용한다.그 이유는 의존관계 때문이다. 이러한 문제 떄문에 throws Exception으로 처리를 하기도 하는데 절대로 사용해선 안되는 코드이다. 그대신 런타임예외를 사용해야한다.
체크 예외의 문제점은 아래의 그림으로 확인할 수 있다.
- 서비스 계층에서는 리포지토리와 NetworkClient를 호출한다.
- 두 곳에서 올라오는 SQLException과 ConnectionException을 처리해야하는데 서비스는 이둘을 처리할 방법을 모른다.(당연하다) - 서비스에서는 SQLException과 ConnectionException을 처리할 수 없으므로 밖으로 던진다.
- 체크 예외이기 떄문에 던질 경우 다음과 같이 선언이 필요하다.- method() throws SQLException, ConnectException
- 컨트롤러도 두 예외를 처리할 방법이 없다.
- 다음을 선언해서 예외를 밖으로 던진다.
- method() throws SQLException, ConnectException - 웹 애플리케이션이라면 서블릿의 오류 페이지나, 또는 스프링 MVC가 제공하는 ControllerAdvice 에서 이런 예외를 공통으로 처리한다
체크 예외의 문제점이 보이는 코드이다.
static class Controller {
Service service = new Service();
public void request() throws SQLException, ConnectException {
service.logic();
}
}
static class Service {
Repository repository = new Repository();
NetworkClient networkClient = new NetworkClient();
public void logic() throws SQLException, ConnectException {
repository.call();
networkClient.call();
}
} 위 코드에서는 2가지 문제가 있다.
1. 복구 불가능한 예외
2. 의존 관계에 대한 문제
복구 불가능한 예외
대부분의 예외는 복구가 불가능하다. 일부 복구가 가능한 예외도 있지만 아주 적다.
SQLException 을 예를 들면 데이터베이스에 무언가 문제가 있어서 발생하는 예외이다. SQL 문법에
문제가 있을 수도 있고, 데이터베이스 자체에 뭔가 문제가 발생했을 수도 있다. 데이터베이스 서버가 중간에
다운 되었을 수도 있다. 이런 문제들은 대부분 복구가 불가능하다. 특히나 대부분의 서비스나 컨트롤러는
이런 문제를 해결할 수는 없다. 따라서 이런 문제들은 일관성 있게 공통으로 처리해야 한다. 오류 로그를
남기고 개발자가 해당 오류를 빠르게 인지하는 것이 필요하다. 서블릿 필터, 스프링 인터셉터, 스프링의
ControllerAdvice 를 사용하면 이런 부분을 깔끔하게 공통으로 해결할 수 있다.
의존 관계에 대한 문제
체크 예외의 또 다른 심각한 문제는 예외에 대한 의존 관계 문제이다.
앞서 대부분의 예외는 복구 불가능한 예외라고 했다. 그런데 체크 예외이기 때문에 컨트롤러나 서비스
입장에서는 본인이 처리할 수 없어도 어쩔 수 없이 throws 를 통해 던지는 예외를 선언해야 한다.
throws SQLException, ConnectionException처럼 예외를 던지는 부분을 코드에 선언하는게 문제가 되는 이유는 의존성 때문이다.
향후 리포지토리를 JDBC기술이 아닌 다른 기술로 변경해야한다면 SQLException이 아닌 JPAException처럼 변할 수 있다.
따라서 SQLException에 의존하던 모든 서비스, 컨트롤러의 코드를 JPAException에 의존하도록 고쳐야한다.
서비스나 컨트롤러 입장에서는 본인이 처리할 수 업슨 예외를 의존해야하는 큰 단점이 발생하게 된다.
정리
- 처리할 수 있는 체크 예외라면 서비스나 컨트롤러에서 처리하겠지만, 지금처럼 데이터베이스나 네트워크
통신처럼 시스템 레벨에서 올라온 예외들은 대부분 복구가 불가능하다. 그리고 실무에서 발생하는 대부분의
예외들은 이런 시스템 예외들이다.- 문제는 이런 경우에 체크 예외를 사용하면 아래에서 올라온 복구 불가능한 예외를 서비스, 컨트롤러 같은
각각의 클래스가 모두 알고 있어야 한다. 그래서 불필요한 의존관계 문제가 발생하게 된다.
언체크 예외 활용(런타임예외 활용)
throws Exception으로 체크 예외를 던지게 되면 컴파일은 통과할 수 있지만 다른 체크 예외까지 기능이 무효화된다. 따라서 런타임 예외를 사용해야한다.
- SQLException을 런타임 예외인 RuntimeSQLException으로 변환해서 전달한다
- ConnectionException 대신 런타임 예외인 RuntimeConnectionException으로 변환해서 전달한다.
- 런타임 예외이기 때문에 서비스, 컨트롤에서는 해당 예외들을 처리할 수 없다면 별도의 선언없이 그냥 두면 된다.
아래는 변환 예시코드이다.
static class Repository {
public void call() {
try {
runSQL();
} catch (SQLException e) {
throw new RuntimeSQLException(e);
}
}
public void runSQL () throws SQLException {
throw new SQLException("ex");
}
}위 코드에서 예외를 변환해서 전달하는데 그떄 예외를 꼭 포함시켜서 전달해야한다.
런타임 예외 - 대부분 복구 불가능한 예외
시스템에서 발생한 예외는 대부분 복구 불가능 예외이다. 런타임 예외를 사용하면 서비스나 컨트롤러가
이런 복구 불가능한 예외를 신경쓰지 않아도 된다. 물론 이렇게 복구 불가능한 예외는 일관성 있게 공통으로
처리해야 한다.
런타임 예외 - 의존 관계에 대한 문제
런타임 예외는 해당 객체가 처리할 수 없는 예외는 무시하면 된다. 따라서 체크 예외 처럼 예외를 강제로
의존하지 않아도 된다
예외 포함과 스택 트레이스
예외를 전환할 때는 꼭! 기존 예외를 포함해야 한다. 그렇지 않으면 스택 트레이스를 확인할 때 심각한문제가 발생한다
예시)
public void call() { try { runSQL(); } catch (SQLException e) { throw new RuntimeSQLException(e); } }
참고
해당 포스팅은 아래의 강의를 공부하여 정리한 내용입니다.
김영한님의 SpringDB1-예외계층
