<토비의스프링> 4.1~4.2 예외

4.1 사라진 SQLException

• 예외를 catch로 잡는 것 까지는 좋은데 아무것도 하지않고 넘기는 것은 위험하다
  • 비정상적인 동작, 메모리나 리소스 소진 등
  • System.out.println 이나 e.printStackTrace 만 찍는것도 문제
    • 화면에 메세지를 출력하는 것은 예외처리 한게 아니다.
• 예외처리 핵심원칙
  1. 적절하게 복구 및 처리
  2. 작업을 중단시키고 운영자 or 개발자에게 분명하게 전달
• throws Exception 으로는 의미있는 정보를 얻을 수 없다.
• 예외의 종류와 특징
  1. Error
     • 시스템에 비정상적인 상황이 발생
       • 주로 Java VM에서 발생시키고 어플리케이션 코드에서 잡으면 안된다.
     • java.lang.Error 클래스의 서브클래스 (OutOfMemoryError, ThreadDeath)
  2. Exception
     • 어플리케이션 코드의 작업 중에 예외상황이 발생했을 경우에 사용
     • java.lang.Exception 클래스와 그 서브클래스, 두가지로 구분
       • Checked Exception
         • 일반적인 예외
         • 반드시 예외처리해야함, 안하면 컴파일에러
       • Unchecked Exception
         • RuntimeException을 상속한 클래스
         • 명시적인 예외처리를 강제하지 않음
         • 오류가 있을때 발생하도록 의도된 것들(NullPointerException,IllegalArgumentException 등)
         • 피할 수 있지만 개발자가 부주의해서 발생
         • 예상하지 못했던 예외상황에서 발생하는게 아니므로 처리하지 않아도 된다(?)
         • 요즘에는 예상 가능한 예외를 체크예외로 만들지 않는 경향이 있음
• 예외처리 방법
  1. 예외복구
     • 상황을 파악하고 문제를 해결해 정상상태로 돌려놓는 것
     • 기본 작업 흐름이 불가능 하면(ex. 파일이 없어짐) 다른 작업흐름으로 유도
  2. 예외 회피
     • 호출한 쪽으로 던져버리는 것
     • 예외를 복구하는 것 처럼 의도가 분명 해야한다.
  3. 예외 전환
     • 예외를 적절한 예외로 전환해서 던져버리는 것
       • 의미를 분명하게 해주는 예외
     • 예외처리를 단순하게 하기위에 Wrap
       • 체크 예외를 런타임 예외로 바꾸는 경우에 사용
• 예외처리 전략
  • 런타임 예외
    • 대응이 불가능한 체크 예외라면 런타임 예외로 전환해서 던지는게 낫다
    • 항상 복구할 수 있는 예외가 아니면 언체크 예외로 만들어지고 있다

 

4.2 예외 전환

• 런타임 예외로 포장해 불필요한 catch/throws 를 줄여주는 것
• 로우레벨의 예외를 좀더 의미 있고 추상화된 예외로 바꿔서 던져주는 것
• DAO는 인터페이스를 사용해 구체적인 클래스 정보와 구현방법을 감추고 DI를 통해 제공
• 중복키 에러가 발생할 경우 기술마다 다른 Excption이 발생, DAO는 기술에따라 달라야함...
  • JDBC → SQLExcption, JPA → PersistenceExcpetion. 하이버네이트 → HibernateExcpetion
• DataAccessException은 엑세스 기술의 종류와 관계 없이 일관된 예외가 발생하도록 만들어줌
  • Spring은 이를 계층구조로 분류
  • 낙관적인 락킹 (JPA같은 오브젝트/엔티티 단위로 정보를 업데이트 하는 경우)
    • 두명 이상의 사용자가 동시조회하고 순차적으로 업데이트할때 뒤늦게 업데이트한것을 덮어쓰지 않도록 막아줌