본문 바로가기
프로그래밍 놀이터/디자인 패턴, 리펙토링

[Effective Java] 복구 가능 상황에서는 checked 예외를 사용하고, 런타임 예외는 프로그램 에러에 사용하자.

by 돼지왕 왕돼지 2017. 2. 21.
반응형

 복구 가능 상황에서는 checked 예외를 사용하고, 런타임 예외는 프로그램 에러에 사용하자.


API, api 명세, catch, checked exception, checked 예외, Effective JAVA, error, jvm, runtime exception, RuntimeException, unchecked exception, [Effective Java] 복구 가능 상황에서는 checked 예외를 사용하고, 런타임 예외, 런타임 예외는 프로그램 에러에 사용하자., 문자열, 변화, 복구, 복구 가능 상황, 불변 규칙, 불변규칙 위반, 사전조건 위반, 예외 복구, 외부, 이식성, 자원 부족, 취약, 프로그래밍 에러, 프로그램 에러


-
자바 언어는 다음 세 종류의 예외를 던질 수 있다.
checked exception, runtime exception, error


-
메소드 호출자가 당연히 예외 복구를 할 수 있는 상황에서는 checked 예외를 사용하자.
checked 예외를 던지면 그 메소드 호출자가 catch 문에서 예외를 처리하거나 또는 외부로 넘겨야 한다.
API 사용자가 checked 예외와 만났다는 것은, 그런 상황을 복구하라는 지시를 그 API 설계자로부터 받은 것이다.


-
unchecked exception 인 runtime exception 과 error 는 catch 할 필요가 없고, 일반적으로 catch 해서도 안 된다.
프로그램에서 unchecked 예외나 에러가 발생했다는 것은 복구가 불가능하고 계속 실행해봐야 더 해롭기만 한 그런 상황이라는 것을 의미한다.


-
런타임 예외를 사용해서 프로그래밍 에러를 나타내자.
대부분의 런타임 예외는 사전조건 위반을 나타낸다.
클라이언트가 그 API 명세에 설정된 계약을 지키지 않은 것을 말한다.


-
에러는 JVM 에서 사용하며, 자원 부족, 불변 규칙 위반에 따른 실패, 또는 JVM 이 실행을 계속할 수 없는 상황 등을 나타낸다.
Error로부터 상속받는 서브 클래스는 만들지 않는게 가장 좋다.
우리가 따로 구현하는 모든 unchecked exception 은 RuntimeException 의 서브클래스여야 한다.



Summary


복구 가능한 상황에는 checked 예외를 사용하고 프로그래밍 에러에는 런타임 예외를 사용하자.
복구가 가능한지 불분명하다면, unchecked 예외를 사용하는 것이 더 좋다.
예외를 문자열로 표현하는 코드는 이식성이 떨어지고, 변화에 취약하다.





반응형

댓글