[2017] 4. 예외

< 초난감예외처리 >

- 예외 블랙홀    : 예외를 잡기만 하고 아무것도 안하는 것

- 무의미하고 무책임한 throws

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

< 예외의 종류와 특징 > 

1. Error

- java.lang.Error 클래스의 서브클래스

- 주로 자바 vm에서 발생시키므로 애플리케이션 코드에서 잡으면 안된다.  (크게 신경안써도 됨)

2. Exception 

1 ) 체크예외

- 반드시 예외를 처리하는 코드를 함께 작성

- 예외 처리 안하면 컴파일에러 

ex) IOException, SQLException

2 ) 언체크예외 (Runtime 예외)

- 피할 수 있지만 개발자가 부주의 해서 발생할 수 있는 경우에 발생 

ex) NullPointerException

< 예외처리 방법 > 

1. 예외복구

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

2. 예외처리 회피

- 자신을 호출한 쪽으로 예외처리를 의도가 분명하게 던져버리는 것

3. 예외전환

- 던지기는 하지만 발생한 예외를 적절한 예외로 전환해서 던진다.

 * 목적

1) 의미를 분명하게 해줄 수 있는 예외로 바꿔주기 위해

ex) 아이디 중복 오류면 DAO에서 SQLException을  DuplicateKeyException으로 바꿔서 던짐

2) 예외를 처리하기 쉽고 단순하게 만들기 위해 포장

- 주로 예외처리를 강제하는 체크 예외를 런타임 예외로 바꾸는 경우에 사용

- 어차피 복구하지 못할 예외라면 애플리케이션 코드에서 런타임 예외로 포장해서 던져라

< 예외처리 전략 > 

1. 런타임 예외의 보편화

- 지금은 항상 복구할 수 있는 예외가 아니라면 일단 언체크 예외로 만드는 경향이 있다. 

언체큰 예외라도 필요하다면 얼마든지 catch 블록으로 잡아서 복구하거나 처리할 수 있다. 

2. add()메서드의 예외처리

3. 애플리케이션 예외

- 시스템 또는 외부의 예외상황이 원인이 아니라, 애플리케이션 자체의 로직에 의해 의도적으로 발생시키고, 

반드시 catch 해서 무엇인가 조취를 취하도록 요구하는 예외

ex) 잔액보다 많은 금액을 출금하려 할때 catch하여 사용자에게 무엇인가 메세지를 띄울때 등

<SQLException은 어떻게 됐나? > 

- 대부분의 SQLException은 복구가 불가능하다.

- 필요도 없는 throws 선언을 하지 말고 가능한 빨리 언체크/런타임 예외로 전환해줘야 한다. 

- 스프링의 jdbcTemplate이 이 예외처리 전략을 따르고 있다. 

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

따라서 jdbcTemplate을 사용하는 UesrDao 메서드에선 꼭 필요한 경우에만 DataAccessException을 잡아서 처리하면 되고 그 외의 경우에는 무시해도 된다. 

- 그 밖에도 스프링의 API 메서드에 정의되어 있는 대부분의 예외는 런타임 예외다. 

따라서 발생 가능한 예외가 있다고 하더라도 이를 처리하도록 강제하지 않는다. 

< 예외 전환 > 

목적

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

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

1. jdbc의 한계

- 인터페이스를 사용하는 객체지향 프로그래밍의 방법의 장점을 잘 경험할 수 있는 것이 JDBC다. 

그러나!

1) 비표준 SQL

- 비표준 SQL은 결국 DAO 코드에 들어가고, 해당 DAO는 특정 DB에 대해 종속적인 코드가 된다

DB의 변경 가능성을 고려해서 유연하게 만들어야 한다면 SQL은 큰 걸림돌이 된다.

2) 호환성없는 SQLException의 DB에러정보

- DB마다 에러의 종류와 원인도 제각각

- SQLException의 getErrorCode()로 가져올 수 있는 DB 에러코드는 DB별로 모두 다르다

 DB의 JDBC 드라이버에서 SQLException을 담을 상태 코드를 정확하게 만들어 주지 않는다. 

-------------------

이를 해결하기 위해 스프링의 jdbc 템플릿은 SQLException 대신 DataAccessException로 예외를 전환하여 사용한다.

장점

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

- 이게 없었으면 쿼리문 날리는 클래스마다 의미없는 throws를 계속 날려야한다.

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

- 안그러면 DB바뀔때마다 각 DB별 에러코드 바뀐거 반영해서 배포해야 한다.