require, check, assert 등을 사용하면 대부분 코틀린 오류를 처리할 수 있지만 이외의 예측하지 못한 상황을 나타내야 하는 경우가 존재한다.
JSON 형식을 파싱하는 라이브러리 구현 시 JSON 파일 형식에 문제가 있다면 JSONParsingException을 발생시키는 것이 좋다.
inline fun <reified T> String.readObject(): T {
//...
if (incorrectSign) {
throw JsonParsingException()
}
}
위에서는 표준 라이브러리에 이를 나타내는 적절한 오류가 없어서 사용자 정의 오류를 사용했다.
하지만 가급적 직접 정의하기 보다는 최대한 표준 라이브러리에 존재하는 오류를 사용하는 것이 좋다.
표준 라이브러리의 예외는 많은 개발자가 알고 있으므로 널리 알려진 요소를 재사용하면 다른 사람들이 API를 더 쉽게 배우고 이해할 수 있다.
- IllegalArgumentException, IllegalStateException
-
IndexOutOfBoundsException
컬렉션 또는 배열에서 인덱스 파라미터 값이 범위를 벗어난 경우
-
ConcurrentModificationException
동시 수정을 금지하는데 발생한 경우
-
UnsupportedOperationException
사용하려던 메소드는 현재 객체에서 사용할 수 없다는 것을 나타냄
기본적으로 사용할 수 없는 메소드는 클래스에 없는 것이 좋다.
사용할 수 없는 메소드를 일부러 두는 경우도 있음 → listOf로 만든 컬렉션은 Immutable임을 알려주기 위한 목적으로 add를 호출 시 무조건 오류가 발생한다.
-
NoSuchElementException
사용자가 사용하려던 요소가 존재하지 않음을 나타냄
책 내용에서 가급적 표준 오류를 다루라고 했지만 아래와 같은 사례도 존재하므로 무조건적으로 표준 오류를 사용하기 보다는 팀 구성원들의 의견을 종합해 처리하는게 좋을 것 같습니다.
- 컨트롤러 레이어에서 JPA의
Dataintegrityviolationexception과 같은 저수준 예외를 활용하는 경우 - require나 check에서 발생시키는 예외가 이미 구현된 예외 처리 구문과 겹쳐 예외를 구분해야 하거나 하는 경우
Reference
- 이펙티브 코틀린 - 프로그래밍 인사이트, 마르친 모스칼라 지음, 윤인성 옮김
개인적인 기록을 위해 작성된 글이라 잘못된 내용이 있을 수 있습니다.
오류가 있다면 댓글을 남겨주세요.