Hope is Postponed Disappointment: A Functional Approach to Error Handling in Kotlin

In software development, errors are inevitable. The real challenge lies not in preventing them, but in how we handle them when they occur. This idea aligns closely with the phrase “Hope is postponed disappointment,” a concept that highlights the uncertainty and fragility of unchecked assumptions. In Kotlin, the functional way of handling errors allows us to replace blind hope with clear, predictable code, minimizing the disappointment that arises from runtime surprises.

The Problem with Traditional Error Handling

In many programming languages, exceptions are the default way to handle errors. While powerful, exceptions often come with a cost—both in performance and clarity. Handling exceptions via try-catch blocks creates a disjointed code flow, where error-handling logic is often separated from the main business logic. This can lead to the very thing we fear most: an unexpected crash.

The functional approach offers a cleaner, more predictable way to handle errors, making it easier to reason about and maintain your code.

The Functional Solution: Either and Result

Kotlin provides some powerful tools for functional error handling, namely the Either type (from libraries like Arrow) and the built-in Result type. These types allow you to explicitly represent success and failure in your code, promoting the idea of handling errors as part of your business logic rather than as side effects.

Either

Either<L, R> is a type that represents a value that can be either a success (Right) or a failure (Left). This removes the need for exceptions and makes error handling part of the return type, so the calling code is forced to deal with both cases.

sealed class Either<out L, out R> {
    data class Left<out L>(val value: L) : Either<L, Nothing>()
    data class Right<out R>(val value: R) : Either<Nothing, R>()
}        

For example, imagine a function that retrieves user data from an API:

fun fetchUser(userId: String): Either<Error, User> {
    return if (userExists(userId)) {
        Either.Right(getUser(userId))
    } else {
        Either.Left(Error("User not found"))
    }
}        

The caller must handle both success and failure cases:

val result = fetchUser("123")
when (result) {
    is Either.Left -> handleError(result.value)
    is Either.Right -> showUser(result.value)
}        

By using Either, you eliminate the potential disappointment of a runtime exception and ensure that error handling is always a part of the flow.

Result

Kotlin’s built-in Result type is another great tool for functional error handling. It provides a similar mechanism to Either, but it is specifically designed for handling success and failure within Kotlin’s standard library.

fun divide(a: Int, b: Int): Result<Int> {
    return if (b != 0) {
        Result.success(a / b)
    } else {
        Result.failure(IllegalArgumentException("Cannot divide by zero"))
    }
}        

Here, the caller must handle both the success and failure cases:

val result = divide(10, 0)
result.onSuccess { println("Result: $it") }
      .onFailure { println("Error: ${it.message}") }        

Using Result, you ensure that errors are no longer hidden in try-catch blocks, but are surfaced as explicit, typed results, leading to more robust and maintainable code.

Mapping and Chaining: Composing Functions Safely

One of the key benefits of functional error handling is the ability to easily chain and compose functions. Using functions like map and flatMap, you can transform and combine Either or Result values without needing to worry about exceptions being thrown in between.

For example:

val finalResult = fetchUser("123")
    .flatMap { user -> validateUser(user) }
    .map { validatedUser -> sendWelcomeEmail(validatedUser) }        

Here, each function is only called if the previous one succeeds. If any step fails, the entire chain is short-circuited, and the error is propagated.

Hope Is Not a Strategy

The essence of functional error handling in Kotlin is that it moves us away from "hoping" that things won’t go wrong and toward explicitly handling every possible outcome. Just as we might say, “hope is postponed disappointment,” we could also say that unchecked exceptions are postponed bugs waiting to happen.

By embracing functional patterns, we create code that is more reliable, predictable, and easier to understand. The cost of functional error handling is a bit of verbosity, but the return is a more resilient system—one that doesn’t rely on blind hope.

In Kotlin, as in life, hope is not a strategy. Handling failure explicitly ensures that when disappointment arrives, it's met with preparedness and grace, rather than a system crash.

Conclusion

If you’re looking to write safer, more predictable Kotlin code, functional error handling with Either or Result is a powerful technique. Not only does it force you to think through how you handle errors, but it also leads to more readable and maintainable code in the long run.

Hope may be postponed disappointment, but with functional error handling, you can ensure that when disappointment does arrive, your system will be ready to handle it.