이펙티브 코틀린 Item 6: 사용자 정의 오류보다는 표준 오류를 사용하라

앞서 5장에서 이야기하는 거처럼 require, check, assert 함수를 사용하면, 대부분의 코틀린 오류를 처리할 수 있다.
하지만 이외에도 예측하지 못한 상황을 나타내야 하는 경우가 있다.

inline fun <reified T> String.readOjbect(): T {
	// ...
    if (incorrectSign) {
    	throw JsonParsingException()
    }
    // ...
    return result
}

이렇게 기본적으로 입력된 Json 파일의 형식에 문제가 있다면, JsonParsingException 등을 발생시키는 것이 좋을 것이다.

보통 표준 오류가 없을 때, 사용자 정의 오류를 사용할 때도 있는데 가능하다면, 직접 오류를 정의하는 것보다는 최대한 표준 라이브러리의 오류를 사용하는 것이 좋다.
왜냐하면 표준 라이브러리의 오류는 많은 개발자가 알고 있으므로 이를 재사용하는 좋기 때문이다.

잘 만들어진 규약을 가진 요소를 재사용하면 다른 사람들이 API를 더 쉽게 배우고 이해할 수 있다!

아래는 일반적으로 사용되는 예외를 정리해봤다.

• IllegalArgumentException, IllegalStateException: require와 check를 사용해 throw 할 수 있는 예외

• IndexOutOfBoundsException: 인덱스 파라미터의 값이 범위를 벗어났다는 예외. 일반적으로 컬렉션 또는 배열과 함께 사용된다. ex) ArrayList.get(Int)를 사용할 때 throw

• ConcureentModificationException: 동시 수정(concurrent modification)을 금지했는데, 발생해 버렸다는 것을 나타난다.

• UnsupportedOperationException: 사용자가 사용하려고 했던 메서드가 현재 객체에서는 사용할 수 없다. 기본적으로 사용할 수 없는 메서드는 클래스에 없는 것이 좋다. (인터페이스 분리 원칙 위반)

• NoSuchElementException: 사용자가 사용하려고 했던 요소가 존재하지 않음을 나타난다. 예를 들어 내부에 요소가 없는 Iterable에 대해 next를 호출할 때 발생한다.