15-Dec

Error Handling in Kotlin Without Exceptions

In this article, we compare error handling methods in Kotlin; specifically: exceptions, Either, and Result.

3 min read

By Simen Fonnes

December 15, 2020

Traditionally, we may use exceptions to handle errors. We perform some action and throw an exception if something goes wrong. But, if you are calling a function, how do you know if it can throw an exception at all? And if it does, what kind of exception? These are hard questions to answer, enter Either:

Either can be used as a typesafe alternative for error handling. Either holds one of two values, a Left or a Right. When we call a function which returns an Either, we are forced to handle both a successful and an unsuccessful case, and get to know exactly what this function returns. On the other hand, if we were to use exceptions, there is no method signature for the developer to see what cases may occur. Developers may annotate a function with @Throws, but since this is optional, it is not dependable. Therefore, with lack of a complete method signature, developers must either ignore the exception or interpret the function body and all possible underlying method calls.

Let us say that we want to validate a user object using an opaque type. Look at the code below. The only way to obtain an instance of ValidatedUser is to provide a RawUser with a valid email address to the static validate function.

data class RawUser(
    val email: String
)

class InvalidEmailException: RuntimeException("Invalid email")

class ValidatedUser private constructor(
    val email: String
) {
    companion object {
        fun validate(rawUser: RawUser): ValidatedUser =
            if (EMAIL_REGEX.matches(rawUser.email)) {
                ValidatedUser(rawUser.email)
            } else {
                throw InvalidEmailException()
            }
    }
}

And we may call it like so:

try {
    println(ValidatedUser.validate(RawUser(emailAddress)).email)
} catch (e: Exception) {
    println(e.message)
}

You may have already noticed that we catch Exception and not InvalidEmailException. This illustrates the main issue with exceptions, they are dynamically typed. The only way to know which exceptions might be thrown is to manually parse the function body (and the body of any internal function calls). This may not always be trivial, for example, if you are calling a function from an external library.

Luckily, there is a neat solution to this problem. Using the same RawUser class, we can implement it using Either from the Arrow library:

enum class ValidationError {
    INVALID_EMAIL
}

class ValidatedUser private constructor(
    val email: String
) {
    companion object {
        fun validate(rawUser: RawUser): Either<ValidationError, ValidatedUser> =
            if (EMAIL_REGEX.matches(rawUser.email)) {
                Either.right(ValidatedUser(rawUser.email))
            } else {
                Either.left(ValidationError.INVALID_EMAIL)
            }
    }
}

when(val validatedUser = ValidatedUser.validate(RawUser(emailAddress))) {
    is Left -> println(validatedUser.a)
    is Right -> println(validatedUser.b)
}

It is crystal clear what this function does from the signature alone. You either get a ValidationError or a ValidatedUser. Because Either is a sealed class, we also get exhaustive pattern matching using when. Additionally, we get smart casting which automatically gives us access to an a (the error) if it is a Left-instance, or a b (the success value) if it is a Right-instance.

There are cons to this approach as well as with exceptions. The choice of whether the error value is in the left or right slot is completely dependent on convention. It is easy to confuse, especially when you are working with different implementations where they are reversed (for example, Result in Rust and Kotlin-result). Consider this, which of these cases prints the error?

when(val validatedUser = ValidatedUser.validate(RawUser(emailAddress))) {
    is Left -> println(validatedUser.a)
    is Right -> println(validatedUser.b)
}

Either is rather generic, and thus, Left and Right may not make sense for the reader by itself. Additionally, you may also notice that Left and Right suddenly change to a and b. Not a huge problem, but readability suffers nonetheless.

If you want all the advantages of Either, but also want to stay semantically accurate in the context of error handling, check out Result<T, E>. Right changes to Ok, and Left to Err. It makes it significantly harder to confuse Left and Right as Ok and Err makes sense in their own right (pun intended).

class ValidatedUser private constructor(
    val email: String
) {
    companion object {
        fun validate(rawUser: RawUser): Result<ValidatedUser, ValidationError> =
            if (EMAIL_REGEX.matches(rawUser.email)) {
                Ok(ValidatedUser(rawUser.email))
            } else {
                Err(ValidationError.INVALID_EMAIL)
            }
    }
}

when(val validatedUser = ValidatedUser.validate(RawUser(emailAddress))) {
    is Ok -> println(validatedUser.value.email)
    is Err -> println(validatedUser.error.name)
}

Ah, delightful!

Up next...

Loading…

Proudly powered by