item 71) 필요 없는 검사 예외 사용은 피하라

1. Error vs Exception

 

 

 

2. unchecked vs checked

 

2-1 Unchecked Exception

- RunTimeException 을 상속 받은 Exception

- throw문이나 try catch 문으로 처리 해주지않아도됨.

- RunTime 시점에서 발생하며, 예외 발생시 트랜잭션 롤백함

- NullPointerException, OutOfBoundsException

 

2-2 Checked Exception

 

- RunTimeException을 상속 하지 않은 Exception 클래스들

- 명시적으로 Throw나 try-catch 문으로 처리해줘야 하고 처리하지 않으면 컴파이 ㄹ에러 발생

- 컴파일 시점에서 체크하며, 예외 발생시 트랜잭션 롤백하지 않음

- IOException , SQLException

- 발생한 문제를 프로그래머가 처리하여 안전성을 높일수 있다.

-프로그래머가 예외에 대해 의미 있는 조취를 할 경우에는 유용함

- Stream에서 사용 불가능.(함수형 프로그래밍 X)

 

package org.springframework.transaction.interceptor;DefaultTransactionAttribute

/* .... */
	@Override
	public boolean rollbackOn(Throwable ex) {
		return (ex instanceof RuntimeException || ex instanceof Error); //에러나 런타임 익셉션(비검사 예외) 일때만 롤백하는 걸 볼수 있다.
	}

 

 

catch(CheckedException e){
	throw new Assertionrror(); //애초에 Error로 처리하면 됐다.
}

catch(CheckedException e){
	e.printStackTrace(); //애초에 비검사 예외로 처리하면 됐다.
    System.exit(1);
}
//의미없는 검사예외처리

3. 검사예외 회피하기

3-1  Optional 사용

- 검사 예외를 던지는 대신에 빈 옵셔널 반환

- 예외가 발생한 이유를 알려주는 정보를 담을수는 없음

 

3-2 검사예외를 던지는 메서드를 2개로 쪼개 비검사 예외로 바꿈

try {
    Obj.action(args);    
} catch (TheCheckedException e) {
    //예외를 처리히ㅏㄴ다.
}
// 메서드 쪼개기 

if (obj.actionPermitted(args)) {
    obj.action(args);
} else {
    //예외를 처리한다.
}

- actionPermitted는 상태 검사 메서드에 해당하므로 여러 스레드에서 동시에 접근하거나 외부 요인에 의해 변할수 있다면 이 리펙토링은 적절하지 않음.

- actionPermited가 action 메서드의 일부분을 중복 수행한다면(검사 체크라던지), 성능면에서 손해임