TIL

4장 예외

4.1 사라진 SQLException

예외가 발생하고 catch 블록으로 잡는 것까지는 좋으나 무시하는 것은 정말 위험한 일이다. 프로그램에 예외가 발생했는데 무시하고 넘어가는 일이기 때문이다.

try {
		if (pstmt != null) {
			pstmt.close();
		}
		} catch (SQLException ignored) {
		}
		try {
			if (conn != null) {
				conn.close();
			}
		} catch (SQLException ignored) {
		}
}

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

4.1.2 예외의 종류와 특징

• Error
  • 시스템에 비정상적인 상황이 발생했을 경우
  • 자바 VM에서 발생시키는 것이고 애플리케이션 코드에서 잡으면 안 된다.
  • 시스템 레벨의 작업을 하는 것이 아니면 개발자는 이 에러에 대해 신경 쓰지 않아도 된다.
• **Exception과 체크 예외**
  • java.lang.Exception 클래스와 그 서브 클래스로 정의되는 예외
  • 체크 예외를 던지면 이를 catch 문으로 잡든지, throws를 정의해서 메서드 밖으로 던져야 한다.
  • 자바, JDK 초기 설계자들은 발생 가능한 예외에 모두 체크 예외를 적용하려고 했던 듯 하다. (IOException, SQLException)
• **RunTimeException과 언체크/런타임 예외**
  • java.lang.RuntimeException 클래스를 상속한 예외
  • catch, throws 등으로 처리를 명시적으로 해줘도 되고 안 해도 된다.
  • NPE나 IllegalArgumentException 등이 있는데 이론 예외는 주의 깊게 코드를 작성하면 피할 수 있다.

체크 예외의 불필요성을 주장하는 사람들이 늘어갔는데 이는 예외 처리의 강제 때문에 catch, throws를 남발하는 코드가 생기기 때문이기도 하다.

최근에 새로 등장하는 자바 표준 API에는 언체크 예외만 쓰는 경향이 있다.

4.1.3 예외 처리 방법

• 예외 복구
  • IO 작업 중 없는 파일에 대해 다른 작업을 하도록 유도
  • 네트워크 접속이 원할하지 않은 경우 다시 접속해 보라고 유도
• 예외 회피
  • throws문으로 던지거나 catch로 잡고 무시
  • 예외를 회피하는 것은 예외를 복구하는 것처럼 의도가 분명해야 한다.
  • 콜백/탬플릿처럼 긴밀한 관계에 있는 다른 오브젝트에게 예외처리 책임을 분명히 지게 하거나 자신을 사용하는 쪽에서 예외를 다루는 게 최선의 방법이라는 분명한 확신이 있어야 한다.
• 예외 전환
  • 예외를 메서드 밖으로 던지지만 다른 예외로 전환해서 던진다는 특징이 있다.
  • 예외 전환의 두 가지 목적
    1. 내부에서 발생한 예외를 그대로 던지는 것이 상황에 대해 적절히 설명하지 못하는 경우 의미를 분명하게 하기 위해서
       1. api가 발생하는 기술적인 로우레벨을 상황에 적합한 의미를 가진 예외로 변경하는 것
    2. 예외를 처리하기 쉽고 단순하게 만들기 위해 포장하는 것
       1. 예외 처리를 강제하는 체크 예외를 언체크 예외로 바꾸는 경우 사용

런타임 예외의 보편화

체크 예외는 catch나 trhows를 강제하기 때문에 개발자의 실수를 방지하기 위한 배려라고 볼 수도 있지만 실제로는 예외를 제대로 다루고 싶지 않을 만큼 짜증나게 만드는 원인이 되기도 한다.

자바가 처음 만들어질 때 많이 사용되던 독립형 애를리케이션에서는 통제 불가한 예외라도 애플리케이션 작업을 중단시키지 않고 상황을 복구해야 했다. 하지만 자바 엔터프라이즈 서버 환경은 다르다. 하나의 요청 중에 예외가 발생하면 해당 작업만 중단시키면 그만이다. (각 요청이 독립적인 작업이기 때문)

자바의 환경이 서버로 이동하면서 체크 예외의 활용도와 가치는 점점 떨어지기 때문에 대응 불가한 체크 예외는 빨리 런타임 예외로 전환해서 던지는 게 낫다.

애플리케이션 예외

애플리케이션 자체의 로직에 의해 의도적으로 발생시키고, 무엇인가 조치를 취하도록 요구하는 예외도 있는데 이를 애플리케이션 예외라고 한다.

4.15 SQLException은 어떻게 됐나?

SQLException은 복구 가능한 예외인가? 99% 확률로 복구 방버비 없다.

• SQL 문법이 틀렸거나
• 제약 조건을 위반했거나
• DB 서버가 다운됐거나
• 네트워크가 불안정하거나
• DB 커넥편 풀이 꽉 찼거나

스프링 JdbcTemplate은 예외 전환 기법을 사용하여 DataAccessException을 던지도록 하고 있다.