4장 - 예외

예외 기본 이해

• Throwable - 최상위 예외

• Error
• 메모리 부족, 심각한 시스템 오류와 같이 복구 불가능한 시스템 예외
• 잡지 말자

• Exception
• 체크 예외
• 컴파일러가 체크해서 thorws 혹은 try-catch 구문을 강제한다
• 장점 - 개발자가 실수로 예외를 누락하지 않도록 컴파일러를 통해 문제를 잡아주는 안전장치
• 단점
• 하지만 실제로는 개발자가 모든 체크 예외를 반드시 잡거나 던지도록 처리해야 하기 때문에, 너무 번거롭다. 크게 신경쓰고 싶지 않은 에외까지 모두 챙겨야 한다.
• 기술이 전파된다.
 
• e.g.) SQLException, IOException

• RuntimeException
• 언체크 예외
• 컴파일러가 체크하지 않는다. 던지면 상위 콜스택으로 계속 던져진다.
• 장점
• 신경쓰고 싶지 않은 언체크 예외를 무시할 수 있다. 체크 예외의 경우 처리할 수 없는 예외를 밖으로 던지려면 항상 throws 예외 를 선언해야 하지만, 언체크 예외는 이 부분을 생략할 수 있다.
• 신경쓰고 싶지 않은 예외의 의존관계를 참조하지 않아도 되는 장점이 있다.
• 단점 - 컴파일러를 통해 예외누락을 잡아지 못한다
• e.g.) NullPointerException, IllegalArgumentException

스프링과 예외

• 서비스 계층은 가급적 특정 기술에 의존적이지 않고 순수하게 유지하는 것이 좋다.

• 이를 위해서 리포지토리는 JDBC, JPA에 종속되지 않은 인터페이스를 제공해야한다.

• 아니면 throws Excpetion 으로 선언해 무책임한 방식을 채택할 수 밖에 없다.

• 이를 위해 체크 예외를 런타임 예외로 전환하는 것이 필요하다.

데이터 접근 예외

• JDBC 드라이버는 DB예외의 종류를 SQLException 의 예외 코드로 구분한다.

• 근데 이 예외는 db 벤더마다 모두 다르고 규약이 있지만 잘 준수되지 않는다.

• 스프링은 db 접근 기술과 관련된 모든 예외를 특정 기술에 종속적이지 않게 추상화하여 제공한다.

• 물론 런타임 예외로!

스프링의 예외 전환 추상화

• 스프링이 추상화된 예외를 제공하였지만 이것을 직접 사용하는것은 또 너무 힘든 일이다. 예외를 잡아 에러 코드를 확인해 알맞은 예외로 전환해서 던져야한다.

• 이 작업은 모든 데이터 계층에 반복적으로 발생할 것이며 심지어 db 타입에 따라 에러코드 등이 살짝살짝 다르다!!

• 스프링은 예외전환기와 예외 전환 aop 를 통해 이를 매우 손쉽게 제공한다.