코틀린은 2010년에 처음 개발되었지만 2016년 2월에 첫 번째 안정 버전(stable version)이 공식적으로 배포되었을 정도로 굉장히 오랜 시간 동안 만들어지고 있고, 처음부터 대규모 애플리케이션을 실용적으로 만들기 위한 프로그래밍 언어로 설계되었고 현재는 모바일 애플리케이션, 웹 애플리케이션의 백엔드, 웹 애플리케이션의 프론트엔드 등 다양한 영역에서 활용되고 있습니다.
7️⃣null과 Failure 사용으로 결과 부족 해결
메서드가 원하는 결과를 만들어 낼 수 없는 경우, 예외를 throw하거나 null 또는 실패를 나타내는 sealed 클래스를 리턴하는 방법이 있습니다.
- 코틀린의 모든 *unchecked 예외이기 때문에 예외를 처리하지 않을 수 있습니다.
- 예외는 예외적인 상황을 처리하기 위해서 만들어졌기 때문에 명시적 테스트(explicit test)만큼 빠르게 동작하지 않습니다.
- try-catch문 내부에 코드를 배치하면, 컴파일러가 할 수 있는 최적화가 제한됩니다.
위와 같은 이유로 예외는 오직 잘못된 특별한 상황을 나타내는 것이지 정보를 전달하는 방법으로 사용해선 안됩니다. 추가적인 정보를 전달하고 싶다면 sealed 클래스를 사용하면 됩니다.
만약 위에서 소개하는 방법으로 오류를 처리하고 싶다면 null과 Failure는 예측할 수 있는 오류를 표현할 때 사용하고, 예측하기 어려운 오류의 경우 예외를 throw해서 처리하면 됩니다.
null을 처리해야 한다면, 사용자는 safe call( ?. ) 또는 Elvis 연산자( ?: ) 같은 다양한 널 안정(null-safety) 기능을 활용하고 RESULT와 같은 공용체를 리턴하기로 했다면, when문을 활용해 처리할 수 있습니다.
sealed class Result<out T>
data class Success<out T>(val result: T): Result<T>()
data class Failure(val throwable: Throwable): Result<Nothing>()
fun takeOrders(foodName: String): Result<Food> {
return when(foodName) {
"Pasta" -> Success(Food(foodName).cook())
"Filure" -> Failure(JsonParsingException())
else -> throw Exception()
}
}
이렇게 오류를 처리하는 방식은 try-catch문 보다 효율적이고 명확합니다.
*checked 예외 : 반드시 처리하게 강제되는 예외
*unchecked 예외 : 처리하지 않아도 실행에 문제가 없는 예외
'Kotlin > 안전성, 가독성을 효과적인 향상시키는 사용법' 카테고리의 다른 글
👋Kotlin : 6️⃣사용자 정의 오류 보다는 표준 오류를 사용 (0) | 2022.03.04 |
---|---|
👋Kotlin : 5️⃣예외를 활용해 코드에 제한을 걸어라 (0) | 2022.03.03 |
👋Kotlin : 4️⃣Inferred(추론된) 타입으로 리턴하지 말라 (0) | 2022.03.01 |
👋Kotlin : 3️⃣최대한 플랫폼 타입 사용을 제한하라 (0) | 2022.03.01 |
👋Kotlin : 2️⃣변수의 스코프 최소화 (0) | 2022.03.01 |