4.1 사라진 SQLException
public void deleteAll() throws SQLException {
this.jdbcContext.executeSql("delete from users");
}
public void deleteAll() {
this.jdbcTemplate.update("delete from users");
}
4.1.1 초난감 예외처리
- 먼저 개발자들의 코드에서 종종 볼 수 있는 잘못된 예외처리를 보자.
예외 블랙홀
try{
...
}
catch(SQLException e){
}
- catch 블록에서 아무것도 안하는 코드
- 프로그램 발생시 예외를 무시하고 그대로 진행
아래와 같은 경우는 괜찮을까?
} catch (SQLException e){
System.out.println(e);
}
} catch (SQLException e){
e.printStackTrace();
}
- 역시 예외를 처리하는 로직이 없으므로 문제가 된다.
- 콘솔이나 서버 실행창에 해당 메시지가 보일지라도 다른 로그나 메시지에 묻혀 놓칠 수 있다.
- 모든 예외는 적절하게 복구, 아니면 작업을 중단시키고 운영자, 개발자에게 통보되게 해야된다.
무의미하고 무책임한 throws
- catch 블록으로 예외를 잡아도 해결할 방법도 없어 자신을 호출한 코드로 예외를 던지는 경우,
각종 이름이 긴 예외를 처리하는 코드를 매번 throws로 선언하기 부담스러워서 이런식으로 던지는 경우다.
public void method1() throws Exception{
method2()
}
public void method2() throws Exception{
method3()
}
public void method3() throws Exception{...}
- 이런 경우 의미 있는 정보를 얻을 수 없다.
- 해당 메소드에서 예외적인 상황이 발생할 수 있는 것인지, 그냥 습관적으로 붙인건지 알 수가 없으며, 적절한 처리로 복구될 수 있는 예외상황도 제대로 다룰 수 없다.
4.1.2 예외의 종류와 특징
- Error
- 거의 자바 vm에서 발생하는 문제로 애플리케이션에서는 해결 방법이 없다. 신경 ㄴㄴ
- 체크 예외 : Exception 클래스의 서브클래스면서 RuntimeException을 상속 받지 않은 클래스
- 언체크 예외 : RuntimeException을 상속한 클래스
- Exception과 체크 예외
- 체크 예외가 발생할 수 있는 메소드를 사용할 경우, 반드시 예외를 처리하는 코드를 함께 작성 해야됨.
- ex) IOException, SQLException
- RuntimeException과 언체크/런타임 예외
- 명시적인 예외처리를 강제 X -> 언체크 예외라고 불림
- 명시적으로 catch하거나 throws로 선언해줘도 상관 ㄴㄴ
- 주로 프로그램의 오류가 있을 때 발생 ex) NullPointerException, IllegalArgumentException
최근에 새로 등장하는 자바 API들은 예외 상황을 다루는 예외는 주로 언체크 예외를 선호한다.
- 체크 예외가 반드시 예외처리를 강제하면서 발생하는 문제가 많기 때문이다.
저놈의 mock을 처라