자바는 문제 상황을 알리는 타입(throwable)으로 검사 예외, 런타임 예외, 에러를 제공한다.
언제 무엇을 사용할지 헷갈리는 프로그래머들이 많기 때문에 참조할 좋은 지침들이 있다.
1. 검사 예외 (Checked Exception)
- Exception 클래스를 상속받은 예외 타입 중에서 RuntimeException을 제외한 나머지 예외들
- 컴파일러가 검사 예외를 체크하고, 예외를 처리하지 않으면 컴파일 오류가 발생한다.
- I/O 문제, 네트워크 연결 실패 등 프로그램의 외부적인 환경 변화에 따른 문제 상황을 나타내는 데 사용된다.
2. 런타임 예외 (Runtime Exception)
- RuntimeException 클래스를 상속받은 예외 타입을 가리킨다.
- 컴파일러가 이 예외를 체크하지 않으며, 예외 처리가 선택 사항이다.
- 배열 인덱스의 범위 초과, NullPointerException, ArithmeticExcetpion 등 실행 시에 발생할 수 있는 프로그래밍 오류나 예측 불가능한 환경 변화에 의한 문제 상황을 나타내는 데 사용된다.
3. 에러 (Error)
- Error 클래스를 상속받은 예외 타입을 가리킨다.
- 주로 시스템 레벨에서 발생하는 치명적인 문제를 나타낸다.
- 메모리 부족, 스택 오버플로우 등과 같이 프로그램이 복구할 수 없는 치명적인 상황을 나타내는 데 사용된다.
검사 예외
호출하는 쪽에서 복구하리라 여겨지는 상황이라면 검사 예외를 사용하라.
- 이것이 검사와 비검사(런타임, 에러) 예외를 구분하는 기본 규칙이다.
- 검사 예외를 던지면 호출자가 그 예외를 catch로 잡아 처리하거나 더 바깥으로 전파하도록 강제하게 된다.
- 따라서 메서드 선언에 포함된 검사 예외 각각은 그 메서드를 호출했을 때 발생할 수 있는 유력한 결과임을 API 사용자에게 알려준다.
검사 예외는 복구할 수 있는 조건일 때 발생하므로 호출자가 예외 상황에서 벗어나는 데 필요한 정보를 알려주는 메서드를 함께 제공하자.
쇼핑몰에서 물건을 구입하려는데 카드 잔고가 부족하여 검사 예외가 발생 -> 해당 예외는 잔고가 얼마나 부족한지를 알려주는 접근자 메서드를 제공해야 한다.
파일을 찾지 못했을 때 - 검사 예외
비검사 예외
- 비검사 예외인 런타임 예외와 에러는 동작 측면에서 다르지 않다.
- 이 둘은 프로그램에서 잡을 필요가 없거나 혹은 통상적으로는 잡지 말아야 한다.
- 프로그램에서 비검사 예외나 에러를 던졌다는 것은 복구가 불가능하거나 더 실행해봐야 득보다는 실이 많다는 뜻이다.
프로그래밍 오류를 나타낼 때는 런타임 예외를 사용하자.
- 런타임 예외의 대부분은 전제조건을 만족하지 못했을 때 발생한다.
- 예를 들어, 배열의 인덱스는 0에서 '배열크기 -1' 사이여야 한다. ArrayIndexOutOfBoundsException 은 이 전제조건이 지켜지지 않았다는 뜻이다.
배열 범위를 벗어났을 때 - 런타임 예외
복구할 수 있는 상황인지 프로그래밍 오류인지 항상 명확히 구분되지 않을 때
- 예를 들어, 자원 고갈은 말도 안되는 크기의 배열을 할당해 생긴 프로그래밍 오류일 수 있고, 진짜로 자원이 부족해서 발생한 문제일 수도 있다.
- API 설계자는 이러한 자원 고갈 상황을 복구 가능하다고 믿는다면 검사 예외를, 그렇지 않다면 런타임 예외를 사용해야 한다.
- 확신하기 어렵다면 비검사 예외를 선택하는 편이 좋다.
에러는 보통 JVM이 자원 부족, 불변식 깨짐 등 더 이상 수행을 계속할 수 없는 상황을 나타낼 때 사용한다.
- Error 클래스를 상속해 하위 클래스를 만드는 일은 업계에 널리 퍼진 규약이다.
- 우리가 구현하는 비검사 throwable은 모두 RuntimeException의 하위 클래스여야 한다.
- Error는 상속하지 말아야 할 뿐 아니라 throw 문으로 직접 던지는 일도 없어야 한다.(AssertionError는 예외)
재귀 호출로 인한 스택 오버플로우 - 에러
결론
- 복구할 수 있는 상황이면 검사 예외를, 프로그래밍 오류라면 비검사 예외를 던지자.
- 확실하지 않다면 비검사 예외를 던지자.
- 검사 예외도 아니고 런타임 예외도 아닌 throwable 은 정의하지도 말자.
- 검사 예외라면 복구에 필요한 정보를 알려주는 메서드도 제공하자.
'Java > Effective Java' 카테고리의 다른 글
[Effective Java] Item 72. 표준 예외를 사용하라 (0) | 2023.08.06 |
---|---|
[Effective Java] Item 71. 필요 없는 검사 예외 사용은 피하라 (0) | 2023.08.06 |
[Effective Java] Item 69. 예외는 진짜 예외 상황에만 사용하라 (0) | 2023.08.05 |
[Effective Java] Item 68. 일반적으로 통용되는 명명 규칙을 따르라 (0) | 2023.08.04 |
[Effective Java] Item 67. 최적화는 신중히 하라 (0) | 2023.08.03 |