• JdbcTemplate을 대표로 하는 스프링의 데이터 액세스 기능에 담겨 있는 예외처리와 관련된 접근방법 알기

chapter 04는 실습 코드가 많지 않기 때문에 소분류 브랜치를 사용하지 않았습니다 ! 

모든 예외는 적절하게 복구되든지, 작업을 중단시키고 운영자 또는 개발자에게 분명하게 통보돼야 한다

• java.lang.Error 클래스의 서브 클래스들

  • 시스템에 비정상적인 상황이 발생했을 경우 사용
  • 특별한 경우가 아니라면 애플리케이션 코드에서 대응할 방법이 없다

• java.lang.Exception 클래스의 서브 클래스들과 체크 예외

  • 개발자들이 만든 애플리케이션 코드의 작업중에 예외상황이 발생했을 경우

    체크 예외 (:compile Error 발생)

    Exception 클래스의 서브 클래스이면서 RuntimeException 클래스를 상송하지 않은 것들

    반드시 처리해야할 예외 ▶ catch 또는 throws를 통해 처리해야한다

    언체크 예외

    RuntimeException 를 상속한 클래스들

    개발자의 부주의로 발생할 수 있는 런타임 예외

    예외처리를 강제하지 않는다

• 예외 복구

  • 예외 상황을 파악하고 문제를 해결해서 정상 상태로 돌려놓는 것

• 예외 처리 회피

  • 예외를 자신이 담당하지 않고 자신을 호출한 쪽으로 던져버리는 방법
  • throws문으로 선언해서 예외가 발생하면 호출 쪽으로 던져지게 함
  • catch문으로 일단 예외를 잡은 후에 로그를 남기고 다시 예외 던지는 것(rethrow)
  • 회피의 의도가 분명해야 한다

• 예외 전환 (exception translation)

  • 예외를 복구해서 정상적인 상태로는 만들 수 있기 때문에 예외를 메소드 밖으로 던짐
  • 예외를 그대로 넘기는 게 아닌 적절한 예외로 전환해서 던진다

  예외 전환이 사용되는 두 가지 목적

  1. 로우 레벨의 예외를 좀 더 의미있고 추상화된 예외로 바꿔서 던지는 것

     발생한 예외를 그대로 던지는 것이 적절한 의미 부여가 어려울 경우, 의미를 분명하게 해줄 수 있는 예외로 변경하기 위해서

  2. 런타임 예외로 포장해서 굳이 필요하지 않은 catch/throws를 줄여주는 것

     예외를 처리하기 쉽고 단순하게 만들기 위해 포장(의미 있는, 복구 가능한 예외가 아닐 때, 런타임 에러로 포장해서 던진다)

중첩 예외 (nested exception)

의미가 분명하게 변경하는 예외에 원래 발생한 예외를 담아 사용

} catch (SQLException e){
    	// 전환할 예외(원래 발생한 예외); 
    throw DuplicateUserIdException(e);
}

} catch (SQLException e){
    	// 전환할 예외().initCause(발생한 근본 예외);  
    throw DuplicateUserIdException().initCause(e);
}

시스템 또는 외부의 예외상황이 원인이 아니라 애플리케이션 자체의 로직에 의해 의도적으로 발생시키고, 반드시 catch해서 무엇인가 조치를 취하도록 요구하는 예외들

⚠ JdbcTemplate의 throws SQLException은 왜 사라졌는가?

SQLException은 대부분이 복구가 불가능한 예외이다.

시스템의 예외이기에 당연히 애플리케이션 레벨에서 복구할 방법이 없기 때문에 Spring의 예외처리 전략을 사용했다.

필요도 없는 기계적인 throws 선언을 방치하지 않고 언체크/런타임 예외로 전환해줌

스프링의 JdbcTemplate 템플릿과 콜백 안에서 발생하는 모든 SQLException을 런타임 예외인 **DataAccessException**으로 포장해서 던져준다

▶

JdbcTemplate을 사용하는 메소드에선 꼭 필요한 경우에만 런타임 예외 **DataAccessException**를 잡아서 처리해주면 되고 나머지는 무시하면 된다

// JdbcTemplate 내부 메소드들을 살펴보면 모두 throws DataAccessException을 발견할 수 있다
@Override
public int update(final String sql) throws DataAccessException {...}

스프링은 DataAccessException이라는 SQLException을 대체할 수 있는 런타임 예외를 정의하고 있을 뿐 아니라, DataAccessException의 서브클래스로 세분화된 예외 클래스들을 정의하고 있다

▶

데이터 액세스 작업 중에 발생할 수 있는 예외 상황을 수십 가지 예외로 분류하고 이를 추상화해 정의한 다양한 예외 클래스를 제공

⚠ SQLException의 비표준 에러코드와 SQL 상태정보에 대한 해결책 필요

⚠ 일일이 DB별로 에러 코드의 종류를 확인하는 작업을 수행하는 것은 부담스럽다

▶ 스프링은 DB별 에러 코드를 분류해서 스프링이 정의한 예외 클래스와 매핑해놓은 에러 코드 매핑 정보 테이블을 만들어두고 이를 이용한다

▶ JdbcTemplate은 SQLException을 단지 런타임 예외인 DataAccessException으로 포장하는 것이 아니라, DB의 에러 코드를 DataAccessException 계층구조의 클래스 중 하나로 매핑해준다

DB 종류를 확인하고 드라이버나 DB 메타정보를 참고해서 적절한 예외 클래스를 선책하기 때문에 DB가 달라져도 같은 종류의 에러라면 동일한 예외를 받을 수 있다

DAO 자바 데이터 액세스 기술에서 독립시키려면 인터페이스 도입과 런타임 예외 전환, 기술에 독립적인 추상화된 예외로 전환이 필요하다

참고 블로그

• https://velog.io/@dahye4321/%ED%86%A0%EB%B9%84%EC%9D%98-%EC%8A%A4%ED%94%84%EB%A7%81-4%EC%9E%A5%EC%9D%84-%EC%9D%BD%EC%9C%BC%EB%A9%B0