10장 예외

효과적으로 예외를 다루는 지침 

 

예외는 진짜 예외 상황에서만 사용하라 

예외 처리를 통해 프로그램 코드를 작성하지말자 -> 예외가 터져야 끝나는 형식의 코드...

흐름의 제어용으로 예외를 터트리지말자

 

복구할 수 있는 상황에는 Checked 예외를, 프로그래밍 오류에는 Runtime 예외를 사용하라

호출하는쪽에서 복구할 수 있는 상황에서는 checked Exception을 사용하자

API 사용자 ( 호출자 ) 에게 다시 복구하라고 요구하는것.

 

복구할 수 있는지 없는지 확신이 안간다면 런타임 예외를 사용하자 

 

필요없는 Checked Exception 사용을 피하라 

컴파일 상에서 예외를 처리하기때문에 checked 예외를 사용하는 메서드를 호출할 경우 

해당 메서드에서 try catch를 하던지 상위 메서드로 throw를 하는 부담이 생긴다.

 

checked Exception을 피하는 가장 좋은 방법은 Optional을 사용하는것.

 

표준 예외를 사용하라 

숙달된 프로그래머는 반복되는 코드를 줄이고 작성된 코드를 재사용하듯이 예외 또한 이미 자바에서 제공하는 빌트인된 예외를 사용하라고한다.

책에서는 예외에서 더 많은 정보를 제공하기를 원하는 경우 표준 예외를 확장하여 사용하길 권장하고있다.

나 역시 개인 프로젝트에서 정해진 errorResponse spec을 맞추기위해 Runtime Exception을 확장한 커스텀 예외를 사용하고 있다.

 

메서드가 던지는 모든 예외를 문서화 하라 

Checked Exception은 항상 따로 선언하고, 각 예외가 발생하는 상황을 JavaDoc의 @throw 태그를 사용해 문서화를 권장하고 있다.

극단적으로 잘못된 예외의 추상화로 throw Exception, throw Thowable을 던지는 형태를 삼가라고 적혀있다.

이러한 잘못된 추상화가 예외가 메서드 호출자에게 대처할 수 없도록 힌트를 주지 못하기 때문

 

가능한 실패 원자적으로 만들라

호출된 메서드가 실패하더라도 해당 객체는 메서드 호출 전 상태를 유지하도록 하자. ( 데이터베이스의 트랜잭션처럼 )

 

메서드를 실패 원자적으로 만드는 방법

1. 불변 객체를 만들자 
   1. 불변객체는 태생적으로 실패 원자적 객체다. 객체 생성 시점후로 절대 변하지 않기 때문에
2. 매개변수의 유효성을 검증하자 
   1. 객체 내부 상태를 변경하기전에 잠재적 예외 가능성을 걸러내자
3. 실패할 가능성이 있는 코드를 객체 내부 상태를 바꾸는 코드보다 앞에 위치시키자.
4. 객체의 임시 복사본에서 작업을 수행한 다음 성공시 객체에 반영하는 방법 
   1. 데이터를 임시 자료구조에 복사해 놓은 다음 예외가 발생하지 않을 경우 반영하는 방법
5. 작업 도중 실패를 가로채는 복구 코드를 작성

 

예외를 무시하지 말라

 

예를 들어 try catch 선언 후 catch에서 아무것도 안하는 코드가 대표적이다.

catch 를 비워두면 예외 처리를 하는 의미가 없어진다!

만약 예외를 무시하기로했다면 주석으로 그렇게 결정된 이유와 예외 변수의 이름도 ignored로 바꿔놓도록하자 

 

절대절대 비어있는 catch 블록을 그냥 넘어가지말자.