Kotlin Result의 onFailure에서 예외를 던지면?

들어가며

Kotlin을 통해 개발을 한 이후로 에러가 발생할 수 있음을 알리고 싶을 때 Result를 적극적으로 활용하고 있습니다.

Java의 Checked Exception과 같이 사용하는 측에서 예외가 발생할 수 있음을 인지할 수 있으면서도, 값으로 성공/실패를 전달하는 특징 덕분에 LSP를 위반하지 않는 장점이 있는데요. 이 덕분에 특정 비즈니스 로직이 아니라 공통으로 사용하는 코드에 가까울수록 개인적으로 Result를 더 적극적으로 활용하고 있습니다.

최근에 Result에서 제공하는 기본 메서드 중 하나인 onFailure에서 예외를 던졌더니 발생했던 일과, 이를 해결하기 위해 택한 간단한 해결책을 다뤄보려 합니다.

풍부하고 다양한 예외

최근에 들어 예외를 잘 상속하여 다양한 상황에 맞춰 활용하고, 그 내용을 풍부하게 유지하기 위해 cause 필드를 활용하는 것에 신경을 쓰며 코드를 작성하려고 노력하고 있습니다.

특히 Sentry와 같은 도구를 사용할 때 예외의 Stack Trace를 잘 쪼개서 보여주기 때문에 에러 추적에 있어 유용하고, 코드에 중복적으로 로깅을 하는 경우르 줄일 수 있어 많은 장점을 느끼고 있습니다.

그러다 보면 사용하는 라이브러리에 의한 예외나 우리가 정의하지 않은 상황에 대한 예외가 발생했을 때, cause에 잘 담고, 우리가 정의한 예외를 던지고 싶은 상황을 자주 마주하게 됩니다.

try-catch를 활용하면 다음과 같이 처리하게 될 것 같습니다.

fun retrieveFoo(): Foo {
    // Prepare values to retrieve foo
    // ...

    return try {
        fooClient.getFoo()
    } catch (e: Exception) {
        throw CustomOnlyForFooException(cause = e)
    }
}

fooClient가 Spring WebClient, Ktor Client와 같이 외부의 의존성이어서 우리가 알지 못하는 예외를 던질 수 있겠지만, CustomOnlyForFooException이라는 Foo만을 위한 예외를 정의해서 조금 더 상황에 부합하는 풍부한 예외를 던지는 상황입니다. 지금은 예시여서 cause만 담았지만, Foo의 id, type 같은 정보를 담아서 더 상황을 잘 표현하는 예외로 만들 수도 있겠죠.

그리고 이 retrieveFoo()를 사용하는 코드가 있다고 가정해보겠습니다. retrieveFoo()에서 예외가 발생할 수 있다는 사실을 알고 있으면 아마 try-catch로 감싸서 호출을 하게 될 것입니다. 그리고 여기서 발생한 예외를 명시적으로 처리해주려면 다시금 CustomOnlyForFooException을 cause에 담아 새로운 예외를 던져줘야겠죠. 여기선 CustomProcessFooException이라고 가정하겠습니다.

fun processFoo(): ProcessFooResponse {
    return try {
        ProcessFooResponse.of(retrieveFoo())
    } catch (e: Exception) {
        throw CustomProcessFooException(cause = e)
    }
}

지금은 예제가 단순하고 상황을 만들기 위한 부분이 있다보니 과한 처리로 보일 수 있지만, 레이어가 많아지고 공통으로 사용하는, 혹은 사용되는 코드가 많아지다 보면 이런 접근이 유용하다고 느끼는 경우가 종종 있습니다.

Result 적용하기

위 코드는 만약 예외가 발생할 경우 사용하는 쪽에서는 예외가 발생함을 알 수 없다는 문제가 있습니다. Kotlin에는 모든 예외를 Unchecked로 다루기 때문에, 사용하는 측에서 예외가 발생할 수 있음을 알려주기 위해 Result를 사용하게 됩니다.

만약 직접 정의한 예외를 사용하지 않는다면 다음과 같이 코드를 작성하게 될 것입니다.

fun retrieveFoo(): Result<Foo> = runCatching {
    // Prepare values to retrieve foo
    // ...

    fooClient.getFoo()
}

fun processFoo(): Result<ProcessFooResponse> {
    return retrieveFoo().map { foo ->
        ProcessFooResponse.of(foo)
    }
}

지금까지는 큰 문제가 없어 보입니다. Result를 활용하여 성공할 경우 변환을 수행하고, 그대로 Result의 형태로 반환하는 코드네요.
그리고 결론적으로 processFoo()를 사용하는 쪽에서도 다음과 같이 코드를 사용하게 될 것입니다. 요번에는 기본값 처리를 하는 경우로 생각해볼게요.

fun handleProcessFoo(): ProcessFooResponse {
    processFoo().getOrElse {
        logger.error(it) { "some error occurred" }
        ProcessFooResponse.DEFAULT
    }
}

보시다시피 Result와 함께라면 필요하다면 기본값 처리를 할 수도, 필요하지 않다면 getOrThrow()로 예외를 던져버릴 수도 있어 한층 유연한 처리가 가능합니다.

직접 정의한 예외 적용, 그리고 문제 발생

그러면 만약 try-catch를 쓸 때처럼 우리가 정의한 예외를 던지고 싶다면 어떻게 할 수 있을까요?
람다를 통해 실패 시 처리를 정의할 수 있는 onFailure를 활용하면 어떨까요?
한번 적용해보겠습니다.

fun retrieveFoo(): Result<Foo> = runCatching {
    // Prepare values to retrieve foo
    // ...

    fooClient.getFoo()
}

fun processFoo(): Result<ProcessFooResponse> {
    return retrieveFoo().map { foo ->
        ProcessFooResponse.of(foo)
    }.onFailure { throw CustomProcessFooException(cause = it) }
}

fun handleProcessFoo(): ProcessFooResponse {
    processFoo().getOrElse {
        logger.error(it) { "some error occurred" }
        ProcessFooResponse.DEFAULT
    }
}

컴파일 에러도 발생하지 않고, 실제로 구동도 잘 됩니다. 하지만 이 코드에는 문제가 있습니다.
바로 onFailure에서 던진 CustomProcessFooException이 processFoo()의 결과값인 Result.failure<ProcessFooResponse>()가 아니라 아예 processFoo()에서 던져진 예외가 된다는 것입니다.
그렇기 때문에 handleProcessFoo()에서 getOrElse를 통한 핸들링을 해도 전혀 적용되지 않게 됩니다. 애초에 Result가 반환되는 것이 아닌 예외가 터져버리기 때문이죠.

그렇다고 해서 다음과 같이 쓸 수도 없습니다.

fun processFoo(): Result<ProcessFooResponse> {
    return retrieveFoo().map { foo ->
        ProcessFooResponse.of(foo)
    }.onFailure { Result.failure(CustomProcessFooException(cause = it)) }
}

onFailure의 시그니처는 다음과 같은데요.

inline fun <T> Result<T>.onFailure(action: (Throwable) -> Unit): Result<T>

action 람다의 반환형이 Unit이기 때문에 Result의 체이닝 결과에 영향을 줄 수 없게 되어 있기 때문입니다. 굳이 해결해보려면 inline fun이라는 점을 이용해서 다음과 같이 직접 반환을 해주면 됩니다.

fun processFoo(): Result<ProcessFooResponse> {
    return retrieveFoo().map { foo ->
        ProcessFooResponse.of(foo)
    }.onFailure { return Result.failure(CustomProcessFooException(cause = it)) }
}

하지만 onFailure 뒤에 체이닝으로 흐름이 더 있다고 가정하면 코드의 가독성이 떨어지는 부분이 되기 쉽습니다.
어떻게 보면 원래 체인의 흐름에 영향을 만들지 않기로 규정되어 있는 곳에서 예기치 않은 영향이 발생하는 것이니까요.

해결책은 접는 것 (fold)

이런 문제는 fold라는 메서드를 통해 해결할 수 있습니다. (사실 접는다기 보다는 예외값과 정상값을 하나의 흐름으로 줄여내는 것에 가깝습니다.)
fold의 시그니처는 다음과 같은데요.

inline fun <R, T> Result<T>.fold(onSuccess: (value: T) -> R, onFailure: (exception: Throwable) -> R): R

fold는 정상 케이스와 실패 케이스에 대해 어떤 값을 반환할 것인지를 람다를 통해 정의할 수 있습니다.
굳이 Result를 반환하도록 명시된 것은 아니다 보니, 다음과 같이 Result.success()와 Result.failure()를 명시적으로 써주긴 해야합니다.

fun retrieveFoo(): Result<Foo> = runCatching {
    // Prepare values to retrieve foo
    // ...

    fooClient.getFoo()
}

fun processFoo(): Result<ProcessFooResponse> {
    return retrieveFoo().fold(
        onSuccess = { foo -> Result.success(ProcessFooResponse.of(foo)) },
        onFailure = { Result.failure(CustomProcessFooException(cause = it)) }
    )
    
}

fun handleProcessFoo(): ProcessFooResponse {
    processFoo().getOrElse {
        logger.error(it) { "some error occurred" }
        ProcessFooResponse.DEFAULT
    }
}

하지만 코드가 훨씬 명시적이게 됐고, Result의 체이닝 흐름에도 영향을 주지 않습니다. 자연스럽게 계속 흘러가게 되죠.

좀 더 짧게!

fold를 좀 들여다보고 있으면 기본으로 제공되는 getOrThrow 역시도 fold로 표현할 수 있음을 알 수 있습니다.

inline fun <T> Result<T>.getOrThrowFold(): T =
    fold(
        onSuccess = { it },
        onFailure = { throw it }
    )

이와 비슷하게 조금만 더 응용해보면 성공 값은 그대로 두고, 실패값만 우리가 원하는 예외로 변환해서 던지는 확장함수도 구현해볼 수 있게 됩니다.

inline fun <T, E : Throwable> Result<T>.mapFailure(
    transform: (Throwable) -> E
): Result<T> =
    fold(
        onSuccess = { Result.success(it) },
        onFailure = { Result.failure(transform(it)) }
    )

예외를 변환하는 transform을 람다로 받는 확장함수를 구현했습니다. 이를 코드에 적용하면 최종적으로 다음과 같이 적용할 수 있습니다.

fun retrieveFoo(): Result<Foo> = runCatching {
    // Prepare values to retrieve foo
    // ...

    fooClient.getFoo()
}.mapFailure { CustomOnlyForFooException(cause = it) }

fun processFoo(): Result<ProcessFooResponse> {
    return retrieveFoo().map { foo ->
        ProcessFooResponse.of(foo)
    }.mapFailure { CustomProcessFooException(cause = it) }
    
}

fun handleProcessFoo(): ProcessFooResponse {
    processFoo().getOrElse {
        logger.error(it) { "some error occurred" }
        ProcessFooResponse.DEFAULT
    }
}

정상 코드의 변환과 예외 코드의 변환을 한층 더 깔끔하게 표현할 수 있게 되었네요. 처음 try-catch를 활용한 것처럼 retrieveFoo()에도 적용해봤습니다.

마치며

어떠신가요?

크게 어렵지 않은 확장 함수 구현을 통해 Result의 체이닝을 지켜내면서 코드를 명시적으로 작성할 수 있게 되었습니다.

onFailure에서 예외를 발생시키게 되면 함수 전체의 호출 스택으로부터 예외가 발생하게 되는 부분은 예기치 못한 문제를 불러올 수 있는데요. 특히 Coroutines 환경에서 문제가 발생하면 Coroutines 특유의 에러 전파로 인해 상당히 추적하기 까다로운 문제로 번지게 됩니다.

그런 상황이 발생하지 않도록 하려면 onFailure의 역할을 명확하게 이해하고, 필요한 경우엔 fold와 같은 다른 메서드를 활용해보는게 좋을 것 같습니다.

이 글이 Result를 슬기롭게 사용하고자 하는 분들께 도움이 되었으면 합니다.

감사합니다.