토비의스프링 4장. 예외
난감한 예외처리
- 모든 예외는 적절하게 처리되던지 프로그램을 중단하여야 한다.
예외의 종류와 특징
- Error
- 복구 불가능한 시스템 레벨의 문제이므로, catch로 잡아서 할 수 있는 것이 없다.
- OutOfMemorryError, ThreadDeath 등이 있다.
- Exception 체크 예외
- Exception을 상속하면서 RuntimeException을 상속하지 않은 예외를 말한다.
- 이 예외들은 코드에서 필수적으로 try-catch-... 블록으로 다루어져야 한다. 컴파일러가 이를 체크한다.
- 쉽게 말하면 코드를 아무리 잘 작성하더라도 발생할 수 있는 예외들이다.
- 로우레벨에서 네트워크, 메모리 등에 원인이 있는 IOException, SQLException 등이 있다.
- RuntimeException과 언체크/런타임 예외
- Exception을 상속하면서 RuntimeException을 상속한 예외를 말한다.
- 프로그램을 허술하게 작성하였을 때 발생하는 예외다. 제약조건 등을 잘 체크하도록 작성했다면 발생하지 않는 에러들이다.
- NullPointerException, IllegalArgumentException 등이 있다
예외는 어떻게 처리할까?
- 예외 복구
- 예외처리 회피 : throws Exception
- 예외 전환 : throws CustomException
- 예외 회피와 유사
- 아이디 중복된 경우 SQLException이 발생 : 구체적이지 않음
- DuplicateUserIdException을 외부로 던지면, 처리하는 객체 입장에선 '아 아이디가 잘못된 상황이구나!' 명확하게 이해할 수 있다.
예외처리의 전략
- 런타임 예외의 보편화
- 예외 전환을 통해 런타임예외로 바꾸어 던진다.
- 복구 불가능한 상황에 불필요한 try catch 블록 사용을 줄이고, 로우레벨의 예외를 의미가 있는 예외로 바꿔 던지는 것이다.
- 애플리케이션 예외
- return 값으로 해당 작업의 결과에 대한 결과를 알려줄 수 있다. return 0(suc), -1(err)
- 어플리케이션 로직에서 의도적으로 발생시키고 예외 처리를 하도록 요구(강제)하는 설계
스프링의 JdbcTemplate
- 스프링의 JdbcTemplate가 던지는 DataAccessException은 SQLException을 포장하는 런타임 예외다.
- 복구가 불가능한 체크 예외를 신경쓰지 않도록 하고, 상세한 예외정보를 일관성 있는 예외로 전환해서 추상화하는 책임도 겸한다.
JDBC의 한계
비표준 SQL
SQLException 에러 정보의 비표준의 난립
DB 에러 코드 매핑을 통환 예외 전환
DAO 인터페이스/ 구현의 분리
- DAO를 따로 만들어서 사용하는 이유
- 로직을 담은 코드를 성격이 다른 코드에서 분리해 놓기 위함
- 전략 패턴을 이용하여 다른 DAO로 바꾸기 쉽도록 하기 위함
- DAO 세부 구현에 상관없이 인터페이스를 통해 쉽게 사용하도록 하기 위함
throws 선언
- DAO에 사용된 DB와 코드는 전략패턴과 DI를 통해 감추는 법을 앞에서 이미 다루었지만, 인터페이스의 메서드 선언에 보이는 예외가 문제가 될 수 있다.
- DAO의 기술에 관계없이 예외 throws 선언을 통일하게 되었다.
모든 예외는 무시할 수 있을까?
- DataAccessException에는 가능한 모든 예외들이 잘 계층화되어 있어, 데이터 엑세스 기술과 구현에 독립적인 DAO를 작성할 수 있다. 일관성 있는 예외 처리가 가능하기 때문이다.
- 어느정도까지는 일관성이 있지만, 만능은 아니다. DB간의 에러 코드를 성실히 번역하는 것과 달리, JPA,JDO등 다른 데이터 엑세스 기술의 경우 에러 코드는 세분화되어 있지 않기 때문이다. 학습 테스트를 작성하며 실제 전환되는 예외의 종류를 확인하여야 한다.
