item 70 JungHyunLyoo - JAVA-JIKIMI/EFFECTIVE-JAVA3 GitHub Wiki

예외 자세히 알아보기

검사 예외와 비검사 예외를 구분하는 기준

어떤 메서드에 예외를 넣으려고 할 때

메서드를 호출하는 클라이언트에서 복구할거라 여겨지는 상황이라면

(오류에 대한 책임을 클라이언트에게 넘기고 싶다면) 검사 예외(checked exception)를,

그렇지 않으면 비검사 예외(unchecked exception)를 사용하자.

검사 예외의 특징(Exception)

Exception 클래스가 바로 대표적인 검사 예외 클래스이다.

(Throwable 클래스도 검사 예외 클래스지만 일반적으로 개발자가 사용하면 안되는

암묵적 규칙이 있으므로 제외하고 생각하자)

메서드 선언에 포함된 검사 예외들은 그 메서드를 호출했을 때 발생할 수 있는

유력한 결과임을 API 클라이언트(사용자)에게 알려준다. 그리고 이에 대한 처리를 강제한다.

사용자가 예외를 catch만 하고 별다른 조치를 취하지 않을 수도 있지만,

이는 보통 좋지 않은 생각이다(item77)

비검사 예외의 특징(RuntimeException)

RuntimeException 클래스가 바로 대표적인 검사 예외 클래스이다.

(Error 클래스도 검사 예외 클래스지만 일반적으로 개발자가 사용하면 안되는

암묵적 규칙이 있으므로 제외하고 생각하자)

이 예외는 프로그램 내에서 catch할 필요가 없거나 catch 하지 말아야 하는 예외다.

프로그램이 비검사 예외를 던졌다는 것은 복구가 불가능하거나 더 실행해봐야

득보다는 실이 많다는 뜻이다. 특별한 경우가 아니면 catch 해봤자 의미없다.

('비검사 예외가 발생한다면 프로그램이 종료돼야 한다' 라는 것처럼 느껴진다)

클라이언트에서 복구해야하는 것을 어떻게 판단하면 좋을까?

기준을 '잘' 세워 올바른 예외를 선택해야 한다.

하지만 일상의 이런저런 많은 일에서도 기준을 '잘' 세우는 것이 쉽지 않듯

예외를 적절히 구분하는 것도 쉽지 않다

복구할 수 있는 (클라이언트가 해결할 수 있는 여지가 있는) 상황인지 혹은

프로그래밍 오류인지가 항상 명확히 구분되지 않는게 현실이다.

예를 들어 자원 고갈은 말도 안되는 크기의 배열을 할당해 생긴

'프로그래밍 오류' 일 수도 있고 '진짜로 자원이 부족해서 발생한 문제' 일 수도 있다.

전자는 복구할 수 없는 비검사 예외이고 후자는 복구할 수 있는 검사 예외이다.

이러한 판단은 전적으로 API 설계자에게 달려있다.

판단하기 힘들다면 비검사 예외를 선택하는것이 나을 것이다(item71)

검사 예외를 사용할 때 주의할 점

검사 예외는 일반적으로 복구할 수 있는 조건일 때 발생하므로, 복구에 필요한 정보를

알려주는 메서드를 함께 제공해야 그 책임을 다하는 것이라고 할 수 있다.

예를 들어, ATM기에서 현금을 인출하려고 할 때 하루에 인출 가능한 한도를 넘어서는 금액을

인출하려고 하면 '하루에 인출 가능한 한도를 넘어섰습니다' 라는 메세지를 사용자에게 띄워줘야 한다.

그래야 사용자는 금액을 재설정해서 인출을 하는 등의 인출 과정 복구(?) 조치를 취할 수 있다.

(인출 전에 한도 메세지를 화면에 미리 보여주면 좋겠지만 문구를 안보는 사람들이 꼭 있기 마련이다)

여담 :: 예외 메서드의 존재 이유

API 설계자들도 예외 역시 어떤 메서드라도 정의할 수 있는 완벽한 객체라는 사실을 잊곤 한다.

예외의 메서드(printStackTrace 등)는 주로 그 예외를 일으킨 상황에 관한 정보를

코드 형태로 전달하는데 쓰인다. 이런 메서드가 없었다면, 프로그래머들은 오류 메세지를

파싱해서 정보를 빼내야 하는데 이는 굉장히 위험할 수 있다. (item12)

왜냐하면 JVM이나 릴리스에 따라 포맷이 달라질 수 있기 때문이다.

(Throwable 클래스들은 대부분 오류 메세지 포맷을 상세히 기술하지 않는다고 한다)