Kotlin Result vs Throwing Exceptions

[jflavio11]

Hello there!

Opening discussion about the use of Kotlin Result class or throwing exceptions in the domain layer of the app.

Both have advantages and disadvantages. I will write some of then:

Advantages

Kotlin Result class	Throwing Exceptions
- The result of the function is deterministic: only success or failure.	- The code is easy to understand since you can handle the custom exceptions that can occur while executing a routine.
- It's more easy to avoid uncontrolled exceptions, since the implementation can catch them and add it to the result object.	- It's easy to map and generate actions by a given custom exception. For instance: retry API call.
	- More linear-readable code.

Disadvantages

Kotlin Result class	Throwing Exceptions
- Hard to maintain since it accepts generics. In three months you won't understand in which parts of the app that Result is being used.	- Since Kotlin has unchecked exceptions, you must be explicit on what exceptions your function can throw.
- You are adding no business logic code to the domain layer. It's easy to get if a getUser function returns an User object and not a Result<User> object.

Example

Let's take a look of differences:

• Using Kotlin Result in interactor

suspend fun getUser(userId: String): Result<User> {
    val user = repository.getUserById(id = userId)
    if(user.emailNotConfirmed) {
        return Result.error(Exception())
    }
    return Result.success(user)
}


// ViewModel

val userResult = getUser(userId = "id-user-123")
if(userResult is Result.success) {
    // go home
} else if(userResult is Result.error) {
    when(userResult.error) {
        is Exception →  // do something
        is AnotherException →  // do other thing?
        else →  /// ???
    }
}

• Throwing exceptions directly

suspend fun getUser(userId: String): User {
    val user = repository.getUserById(id = userId)
    if(user.emailNotConfirmed) {
        throw UserEmailNotConfirmedException(userId)
    }
    return user
}

// ViewModel
// note that we can use a CoroutineExceptionHandler or map all the exceptions in a mapper class 
try {
    val user = getUser(userId = "id-user-123")
    // go home
} catch(e: UserEmailNotConfirmedException) {
    // start confirm email flow
} catch(e: AnotherException) {
    // another thing
} catch(e: Exception) {
    // generic action
}

What do you think?

IMHO, I think throwing exceptions work very good in most of the cases and should be the way to go for the project, but I'm open to read different point of views.

[deanayac1987]

To manage the backend with FIREBASE we are not going to use additional exceptions that already come to us by default. We can start implementing Kotlin Result, and in the case that we have to consume an API with a custom error handler we could choose
by ThrowingExceptions. It will depend on the context

[Bruno125]

My main issue with exceptions is that, even if properly annotated with @Throws, Kotlin does not enforce catching, right? When used out in the wild, I've seen either no catch (so app crashes), or generic catch(error: Exception). I feel like error scenario is more likely to be handled with Result, so my vote goes for that option too.

Hard to maintain since it accepts generics. In three months you won't understand in which parts of the app that Result is being used.

I think that as long as we remain consistent, this shouldn't be too much of a problem. Result is pretty standard and straightforward (much easier to understand compared to other options such as Arrow's Either for example), so even people with little context on the codebase could see the import and quickly realize what the Result is declaring: success / error data.

[jflavio11]

About the coment of @deanayac → I think we should not pass any external datasource exception to the domain or presentation layer. It will be clean to cast/map them to custom error objects or exceptions.

About @Bruno125 → Yeah. I see that for building features that other devs will use, having non-checked exceptions could guide us to errors.

Now, @Bruno125 @deanayac1987, right now there's a custom ResultType class in the code base, it accepts generics (in my experiences, I had to fight to find the implementations in the IDE), should we still use it or should we go with Kotlin Result class?

[jflavio11]

After some experience coding with both approaches, I'm going with the use of Kotlin Result class. The exception will be mapped in an ErrorMapped to a custom Error class.

Closing discussion.