[토비의 스프링 3.1 Vol.1] 4장 예외

  [사족]

  4장도 3번째 정도 보는 것 같다. 예외는 토비님의 말대로 많은 개발자들이 제법 귀찮아 하는 부분이다. 당장 돌아가는 기능이랑은 별로 상관 없다고 생각되기 쉽기 때문이다. 하지만 그 중요성은 누구나 다 알것이다. 99% 잘 돌아가다가도 1%의 예외 가능성 때문에 시스템이 장애가 나고 다운이 된다면 그건 불완전한 소프트웨어가 되버린다. 그만큼 디테일, 장인정신, 꼼꼼함이 필요한 것이 예외처리다. 자바8이나 스칼라 같은데는 null처리 같은 예외상황에 안전하게 대처하기 위해 Option이 있다. 스펙에 포함될 정도로 예외처리와 관련된 것은 중요하고 꼭 필요한 것이다.

  4장까지 봤을때 스프링을 사용하는 가장 큰 이유는 "유연한 시스템 개발"인 것 같다. 인터페이스를 활용하여 느슨한 결합을 유지하고, 스프링 빈을 이용하여 의존성을 역전 및 관리해서 객체지향적이고 유지보수가 쉬운 시스템을 만드는 것, 이것이 바로 스프링의 제일 큰 장점인 것 같다. 즉, 자바를 더 객체지향적으로 사용할 수 있게 해주는 것이다.

 

  [내용]

  4장의 목차

4.1 사라진 SQLException

4.2 예외 전환

4.3 정리

 

  3장에서 직접 구현한 JdbcContext에서는 메소드에 throws SQLException이 있었는데 JdbcTemplate으로 바꾸면서 사라졌다. 그 이유를 시작으로 4장을 풀어나간다.

  예외가 귀찮다고 해서 다음과 같이 처리하면 안된다.

• catch문에서 잡고 아무 처리도 하지 않음 => 예외임에도 불구하고 정상적인 상황인 것처럼 속임
• catch문에서 잡고 로그만 남김 => 계속 로그를 모니터링하지 않는 이상 언제 처리할지 모름
• 메소드에서 throws로 계속 던짐 => 적절한 처리를 통해 복구될 수 있는 예외상황도 제대로 다룰 수 있는 기회를 박탈당함

예외 처리의 핵심 원칙

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

(P. 281)

예외의 종류와 특징

• Error: 시스템에 뭔가 비정상적인 상황이 발생했을 경우 사용됨. 개발자가 어떻게 할 수 없음.
• Exception
• 체크예외: 반드시 처리해야하는 예외. 처리하지 않으면 컴파일러 에러 발생
• 언체크 예외(extends RuntimeException): 런타임예외라고도 함. 조건 체크를 잘 하면 피할 수 있음. 개발자의 부주의에 의해 발생가능.

예외처리 방법

• 예외 복구: 예외상황을 파악하고 문제를 해결해서 정상 상태로 돌려놓음.
• 예외 회피: 예외를 자신이 처리하지 않고 자신을 호출한 쪽으로 던짐.
• 예외 전환: 예외 회피와 비슷하나 그대로 넘기지 않고 적절한 예외로 전환해서 던짐.

  4장에서는 "예외 전환"과 관련하여 스프링의 예외처리를 설명한다. DataAccessException을 사용하면 데이터 액세스 기술에 의존하지 않고(JDBC, JPA, JDO, Hibernate등에 관계없이) 일관된 예외처리가 가능하다. 인터페이스로 연결해서 특정 DAO기술은 빈을 교체해서 사용할 수 있다.