자바 예외

1. 예외 계층

• Throwable : 최상위 예외이다.
• Throwable을 사용해서 잡는다면 checked Exception도 잡아 버리기 때문에 사용하면 안된다.

• Error : (checked Exception)
• 메모리 부족이나 심각한 시스템 오류와 같이 애플리케이션에서 복구 불가능한 시스템 예외이다.
• 애플리케이션 개발자는 이 예외를 잡으려고 해서는 안된다.
• Throwable 예외를 잡으면 안된다.
• Error 예외도 함께 잡힐 수 있다.

• Exception : 체크 예외
• 애플리케이션 로직에서 사용할 수 있는 실질적인 최상위 예외이다.
• Exception과 그 하위 예외는 모두 컴파일러가 체크하는 체크 예외이다. 단 RuntimeException은 예외로 한다.

• RuntimeException : 언체크 예외, 런타임 예외
• 컴파일러가 체크 하지 않는 언체크 예외이다.
• RuntimeException과 그 자식 예외는 모두 언체크 예외이다.
• RuntimeException의 이름을 따라서 RuntimeException과 그 하위 언체크 예외를 런타임 예외라고 많이 부른다.

2. 예외 기본 규칙

• 5번에서 예외를 처리하면 이후에는 애플리케이션 로직이 정상 흐름으로 동작한다.

• 예외를 처리하지 못하면 호출한 곳에서 예외를 계속 던지게 된다.

2가지 기본 규칙

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

2. 예외를 잡거나 던질 때 지정한 예외뿐만 아니라 그 예외의 자식들도 함께 처리된다.
• 예를들어서 Exception을 catch로 잡으면 그 하위 예외들도 모두 잡을 수 있다.
• 예를 들어서 Exception을 throws로 던지면 그 하위 예외들도 모두 던질 수 있다.

“예외를 처리하지 못하고 계속 던지면 어떻게 될까?”

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

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

3. 체크 예외 VS 언체크 예외

체크 예외

• Exception 중 RuntimeException을 제외한 부분

“Checked 예외의 장단점”

• 장점 :
• 개발자가 실수로 예외를 누락하지 않도록 컴파일러를 통해 문제를 잡아 준다.

• 단점 :
• 신경쓰고 싶지 않은 예외까지 모두 챙겨야 한다.
• 개발시에 외부 라이브러리 사용하는 경우 수많은 체크 예외가 있다.
• 추가로 의존관계에 따른 단점도 있다.
• controller의 controller advice나 filter까지 가서 예외를 처리해야 할 때 전부 throws 해야 하기 때문에 의존관계가 생긴다.

언체크 예외

• RuntimeException과 그 하위 예외는 언체크 예외로 분류된다.

• throws를 선언하지 않고 생략할 수 있다. 이 경우 자동으로 예외를 던진다.

“언체크 예외의 장단점”

• 장점 : 신경쓰고 싶지 않은 언체크 예외를 무시할 수 있다.

• 단점 : 언체크 예외는 개발자가 실수로 예외를 누락할 수 있다.

4. 예외 활용

“기본 원칙은 다음 2가지 기억하자”

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

• 체크 예외는 비즈니스 로직상 의도적으로 던지는 예외에만 사용하자. (최근 트랜드상 잘 사용하지 X)
• 이 경우 해당 예외를 잡아서 반드시 처리해야 하는 문제일 때만 체크 예외를 사용해야 한다. 예를 들어서 다음과 같은 경우가 있다.
• 체크 예외 예)
• 계좌 이체 실패 예외
• 결제시 포인트 부족 예외
• 로그인 ID, PW 불일치 예외

런타임에러로하고 메뉴얼에 적는 방법을 선택할 때도 있다.

“체크 예외의 문제점”

• Repository는 DB에 접근해서 데이터를 저장하고 관리한다. 여기서는 SQLException 체크 예외를 던진다.

• NetworkClient는 외부 네트워크에 접속해서 어떤 기능을 처리하는 객체이다. 여기서는 ConnectionException 체크 예외를 던진다.

• 서비스는 Repository와 NetworkClient를 둘다 호출한다.
• 따라서 두곳에서 올라오는 체크 예외인 SQLException과 ConnectionException을 처리해야 한다.
• 그런데 서비스는 이둘을 처리할 방법을 모른다. ConnectionException처럼 연결이 실패하거나, SQLException 처럼 데이터베이스에서 발생하는 문제처럼 심각한 문제들은 대부분 애플리케이션 로직에서 처리할 방법이 없다.

• 서비스는 SQLException과 ConnectionException를 처리할 수 없으므로 둘다 밖으로 던진다.
• 체크 예외이기 때문에 선언해야 한다.

• Controller도 두 예외를 처리할 방법이 없다.
• 선언해서 예외를 밖으로 던진다.

• 웹 애플리케이션이라면 서블릿의 오류 페이지나, 또는 스프링 MVC가 제공하는 ControllerAdvice에서 이런 예외를 공통으로 처리한다.
• 이런 문제를 보통 사용자에게 어떤 문제가 발생했는지 자세히 설명하기 어렵다. 그래서 사용자에게는 “서비스에 문제가 있습니다.” 라는 일반적인 메세지를 보여준다.
• API라면 보통 HTTP 상태코드 500(내부 서버 오류)을 사용해서 응답을 내려준다.
 

“2가지 문제”

1. 복구 불가능한 예외

2. 의존 관계에 대한 문제

“1. 복구 불가능한 예외”

• SQL 문법에 문제가 있을 수도 있고,

• 데이터베이스 자체에 뭔가 문제가 발생했을 수도 있다.

• 데이터베이스 서버가 중간에 다운 되었을 수도 있다.

서블릿 필터, 스프링 인터셉터, 스프링의 ControllerAdvice를 사용

“2. 의존 관계에 대한 문제”

public void accountTransfer(String fromId, String toId, int money) throws SQLException {...}

언체크 예외 활용

• SQLException을 런타임 예외인 RuntimeSQLException으로 변환

• ConnectionException 대신에 RuntimeConnectionException으로 변환

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

스프링 데이터 접근 예외 계층

• 각각의 예외는 특정 기술에 종속적이지 않게 설계되어있다. 따라서 서비스 계층에서도 스프링이 제공하는 예외를 사용하면 된다. 예를 들어서 JDBC 기술을 사용하든, JPA 기술을 사용하든 스프링이 제공하는 예외를 사용하면 된다.

• JDBC나 JPA를 사용할 때 발생하는 예외를 스프링이 제공하는 예외로 변환해주는 역할도 스프링이 제공한다.

분류

• DataAccessException: 스프링 제공 예외의 최상위 예외 (런타임 예외)

• TransientException: 동일 SQL을 다시 시도했을 때 성공할 가능성이 있는 일시적 예외
• 예시: 쿼리 타임아웃, 락

• NonTransientException: 일시적이지 않음, 같은 SQL을 아무리 반복해서 시도해도 실패
• 예시: SQL 문법 오류, DB 제약조건 위배

스프링 예외 번역기

• 스프링은 DB에러코드를 읽어들여, 상황에 맞는 예외로 알아서 변환해 준다.

try {
    ...
} catch (SQLException e) {
    throw exceptionTranslator.translate("save", sql, e);
}

• translate() 메서드
• 파라미터1: 읽을 수 있는 설명
• 파라미터2: 실행한 SQL
• 파라미터3: 발생한 Exception

• 이렇게 하면 적절한 스프링 데이터 접근 계층의 예외로 변환해서 변환해 반환해준다.

• SQL 문법이 잘못되어 있다면 BadSqlGrammarException을 반환

JdbcTemplate

• JDBC로 개발할 때 발생하는 반복을 대부분 해결해준다.

• 트랜잭션을 위한 커넥션 동기화 자동 실행

• 예외 발생시 스프링 예외 변환기 자동 실행