How Monads and Functional Programming Can Improve Your Exception Handling in Kotlin

Mar 3, 2025 - ⧖ 14 min

Introduction

If you've been programming in Kotlin or Java, you're probably used to handling errors with try-catch blocks. While this approach is standard, it can become really messy in complex scenarios, leading to verbose and difficult-to-maintain code. More critically, traditional exception handling forces developers to constantly anticipate where exceptions might be thrown, increasing cognitive load and potential oversight.

Functional programming offers a powerful set of tools for improving code quality, especially when it comes to error handling. The goal here is to focus on the core concepts that can help you write cleaner, more robust, and more predictable error-handling code. I’m not here to dive into Haskell or push its philosophical depths, being really honest I’m very scared of the Haskell nerds in general. Instead, I’ll explore how these functional programming ideas can be practically applied in Kotlin, with real-world use cases in mind.

One such concept is the monad, which provides a structured approach to handling side effects, errors, and sequencing operations. In Kotlin, while not purely functional, it can achieve some of these principles through libraries like kotlin-result.

Basically, in this post I'll try to cover:

  1. Why traditional exception handling can be problematic.
  2. Core functional programming concepts relevant to error handling.
  3. How kotlin-result addresses these concerns.
  4. Designing APIs with Error Handling in Mind
  5. Addressing the errors listed in 1 using kotlin-result and functional programming concepts.

The Problem: Traditional Exception Handling

Traditional exception handling introduces several issues that can compromise code clarity, reliability, and make it a complete mess. Below I've listed some common problematic uses:

  • Hidden Control Flow: Exception-based error handling introduces invisible jumps in your code execution, making it hard to follow:

    fun processUser(user: User) {
    validateUser(user)
    updateProfile(user)
    notifyUser(user)
}

    Any of these functions could throw an exception, turning the flow unpredictable. This way, Raymond Chen from Microsoft describes exceptions as "Exceptions are like non-local goto statements" which results in:

    • Hard-to-trace execution paths.
    • Unintended disruptions.
    • Increased difficulty in ensuring consistent error handling.

    A better approach would make errors explicit and handle them systematically.

  • The Checked vs. Unchecked Dilemma: Checked exceptions in Java force developers to catch and handle exceptions at every step, cluttering codebases:

    try {
    fileOperation()  // throws IOException
    networkCall()    // throws NetworkException
    dbOperation()    // throws SQLException
} catch (IOException e) {
    // Handle file error
} catch (NetworkException e) {
    // Handle network error
} catch (SQLException e) {
    // Handle DB error
}

    Unchecked exceptions, while more flexible, introduce uncertainty, as function signatures do not explicitly indicate possible failure cases.

  • Resource Management Complexity: Managing resources manually often leads to nested try-finally blocks that makes code difficult to maintain and understand later on:

    fun processOrders() {
    val connection = dataSource.connection
    try {
        val statement = connection.createStatement()
        try {
            val result = statement.executeQuery("SELECT * FROM orders")
            try {
                // Process result
            } finally {
                result.close()
            }
        } finally {
            statement.close()
        }
    } finally {
        connection.close()
    }
}

    This structure is:

    • Verbose and difficult to read.
    • Vulnerable to resource leaks if exceptions are not handled correctly.
    • Hard to maintain.

    This just looks ugly overall, let's be honest.

  • Loss of Type Safety: Traditional exceptions break type safety because failure conditions are not represented in function signatures:

    fun getUserProfile(id: String): UserProfile {
    // This function might throw exceptions that aren’t apparent from the signature. That's one of the most important points of the post
    throw new UserNotFoundException()
}

    This approach:

    • Leads to unexpected runtime failures.
    • Reduces predictability in API contracts.
    • Makes error handling an afterthought instead of a first-class concern.

Core Functional Programming Concepts Relevant to Error Handling

What is Functional Programming?

Functional programming is a paradigm where functions are treated as first-class citizens, and computation is done through the evaluation of EXPRESSIONS rather than the execution of statements(like mostly done in imperative languages C, java, cpp...). It emphasizes immutability, no side effects, and the use of pure functions. This paradigm, while vast with numerous research areas like lambda calculus, category theory, and type systems, provides a lot of nerdy tools for managing complexity in software. I'd recommend this lecture if you want to dive deeper in some o these topics or if you really hate yourself -> "Learn You a Haskell for Great Good!" by Miran Lipovaca (link) and Haskell.org for deeper dives into functional concepts.

Key Points:

  • Immutability: Data cannot be changed once created, promoting safer parallel processing.
  • Pure Functions: Functions always produce the same output for the same input, without affecting or being affected by the external behaviors.
  • Higher-Order Functions: Functions can take other functions as arguments or return them.

This post will focus only on a few of these concepts, particularly functors and monads.

Functors: Safe Value Transformations

Functor is like a box or container. You can apply a transformation (or function) to what's inside the box without opening it. In programming terms, this means you can alter or map over the contents of a data structure without changing its structure:

  • List as a Functor: If you have a list of numbers, you can double each number without altering the list itself:

      val numbers = listOf(1, 2, 3)
  val doubled = numbers.map { it * 2 } // [2, 4, 6]

  • Conceptually: Functors allow you to work with data in a way that's safe and predictable because you're not directly manipulating the data but rather transforming it through a mapping operation.

Monads: Chaining Operations with Context

Monads extend the concept of functors by allowing operations to be chained together while preserving some form of 'context' or 'state':

  • Monad: Monads help to ensure that each step in the sequence is checked before proceeding. It sounds complex(and it possibly is a little bit) but it's a way to wrapping things and provide methods to do operations on the wrapped stuff without unwrapping it.

    Let's take an example to make it more practical, consider monads as the operation of baking a cake. You need flour before you can add eggs. If there's no flour, you don't add the eggs.

  • In Code: Monads provide a way to wrap values in context, manage that context through operations, and decide on the next step based on the outcome of the previous one:

      val maybeFlour = checkForFlour()
  val maybeCake = maybeFlour.flatMap { flour -> 
      if (flour) {
          addEggs()
      } else {
          Result.failure(NoFlourException())
      }
  }

  • Practical Use: In error handling, monads can encapsulate whether an operation was successful or not, allowing you to sequence operations where one depends on the success of another without explicit exception checks.

How kotlin-result Addresses These Concerns

kotlin-result is a Kotlin library that encapsulates the monadic approach to error handling, offering a Result type which is a monadic type that holds either a successful value or an error. Here's how it adress some issues:

  • Explicit Success or Failure: Rather than using exceptions, Result explicitly represents outcomes as either success (Result.Success) or failure (Result.Failure). This makes error paths clear and predictable, every call should return success or failure.

  • Type-Safe Error Handling: By leveraging sealed classes for error types, kotlin-result ensures at compile-time that all possible outcomes are accounted for. This prevents runtime surprises, similar to how a monadic type system ensures all paths are considered.

  • Reduces Error Boilerplate: The library allows operations to be chained with methods like map, flatMap, or andThen. This reduces the need for extensive try-catch blocks, promoting cleaner code by handling errors in a functional manner.

  • Resource Management: Combining Kotlin's scope functions with Result simplifies resource management. Operations can ensure resources are released properly, even on failure, without the clutter of nested try-finally blocks.

  • Promotes Composable Code: Functions return Result types, enabling them to be composed into more complex operations. This modularity and reusability reflect the functional programming ethos of treating functions as building blocks.

Key Use Cases

  • Replacing Traditional Exception Handling: When you want to avoid exceptions for scenarios where error is part of the normal flow, like input validation or network calls. Instead of exceptions, you return Result to explicitly handle both success and failure.

  • API Design: When designing APIs, kotlin-result helps in creating interfaces that are clear about what can go wrong, allowing clients to handle errors gracefully without exception handling boilerplate.

  • Error Propagation: In large codebases, propagating errors up the call stack can be done in a way that's clear and doesn't rely on exceptions, making the code easier to navigate and understand.

Designing APIs with Error Handling in Mind

When you're designing your Kotlin APIs, consider the following to ensure your error handling is effective:

  • Use Exceptions only when strictly needed: Reserve exceptions for true programming errors where recovery is not feasible, like accessing an index out of bounds in an array. These signify bugs that should be caught and reported, not handled routinely.

  • Use Result for Flow: For scenarios where failure is part of normal operation (like validation, network calls, or data parsing), return Result types. This makes error handling explicit, giving you control over how failures are managed without resorting to exceptions.

  • Wrap logic and adapt it: When you're interfacing with legacy or external APIs that throw exceptions for conditions that aren't logic errors, wrap these calls. Create functions that transform exceptions into Result types, giving your API users a cleaner, more predictable interface:

      fun fetchUserData(userId: Int): Result<UserData, NetworkError> {
      return try {
          Result.success(api.getUserData(userId))
      } catch (e: IOException) {
          Result.failure(NetworkError.IOError(e.message ?: "Network error"))
      } catch (e: TimeoutException) {
          Result.failure(NetworkError.Timeout("Request timed out"))
      }
  }

  // Where NetworkError could be defined as:
  sealed class NetworkError {
      data class IOError(val message: String) : NetworkError()
      data class Timeout(val message: String) : NetworkError()
  }

  • Multiple Error Scenarios: For functions that can fail in various ways, define a sealed class to represent these outcomes:

      sealed class InputError {
      data class Empty(val field: String) : InputError()
      data class InvalidFormat(val field: String, val reason: String) : InputError()
      data class OutOfRange(val field: String) : InputError()
  }

Addressing the Problems Listed in first section Using kotlin-result

Example 1: Hidden Control Flow

Instead of implicit exception flow:

  • Problem: Exceptions make execution unpredictable—any call could derail the flow.

  • Solution with Result: Make every step of the process explicit:

      fun processUser(user: User): Result<ProcessedUser, UserError> =
      validateUser(user)
          .andThen { updateProfile(it) }
          .andThen { notifyUser(it) }

  • Why It Works: Instead of invisible jumps, each function returns a Result, letting you handle success or failure explicitly. The flow stays linear and predictable, directly addressing the "non-local goto" issue.

Example 2: Checked vs. Unchecked Dilemma

  • Problem: The approach listed in 1 bloats code with repetitive handling or leaves failures undocumented if unchecked exceptions are used.

  • Solution with Result: Consolidate errors into a single, type-safe return type:

      sealed class OperationError {
      data class FileError(val message: String) : OperationError()
      data class NetworkError(val message: String) : OperationError()
      data class DatabaseError(val message: String) : OperationError()
  }

  fun performOperations(): Result<SuccessData, OperationError> =
      fileOperation().andThen { networkCall() }.andThen { dbOperation() }

  fun fileOperation(): Result<Unit, OperationError.FileError> = try {
      // File logic
      Result.success(Unit)
  } catch (e: IOException) {
      Result.failure(OperationError.FileError(e.message ?: "File error"))
  }

  fun networkCall(): Result<Unit, OperationError.NetworkError> = try {
      // Network logic
      Result.success(Unit)
  } catch (e: NetworkException) {
      Result.failure(OperationError.NetworkError(e.message ?: "Network error"))
  }

  fun dbOperation(): Result<SuccessData, OperationError.DatabaseError> = try {
      // DB logic
      Result.success(SuccessData())
  } catch (e: SQLException) {
      Result.failure(OperationError.DatabaseError(e.message ?: "DB error"))
  }

  • Why It Works: Instead of the messy code with multiple catch blocks or risking hidden unchecked exceptions, Result wraps all possible failures into a single OperationError hierarchy. The andThen chaining ensures each step only proceeds if the previous one succeeds, making errors explicit in the function signatures. This eliminates verbosity, ensures type-safe handling with Kotlin when expression downstream, and resolves the checked vs. unchecked trade-off by making every failure mode clear and manageable.

Example 3: Resource Management Complexity

  • Problem: Managing resources with try-finally blocks are verbose and leak-prone.

  • Solution with Result: Combine Result with Kotlin functions use:

      fun processOrders(): Result<List<Order>, DBError> =
      dataSource.connection.use { connection ->
          connection.createStatement().use { statement ->
              statement.executeQuery("SELECT * FROM orders").use { result ->
                  runCatching { result.toOrders() }
                      .mapError { DBError.QueryFailed(it.message) }
              }
          }
      }

  • Why It Works: use auto-closes resources, and Result captures errors, eliminating nesting. This directly simplifies the ugly, error-prone structure from before.

Example 4: Loss of Type Safety

  • Problem: Exceptions hide failure modes, breaking type safety. This is a very simple example, but possibly the biggest catch of the post. See how calling the function getUserProfile makes it now easier to understand and manage errors in the domain of the codebase.

  • Solution with Result: Functions return Result with explicit error type:

      fun getUserProfile(id: String): Result<UserProfile, UserFetchError> = try {
      Result.success(database.getUserProfile(id))
  } catch (e: SQLException) {
      Result.failure(UserFetchError.DatabaseError(e.message ?: "Unknown error"))
  }

  • Why It Works: The signature now declares possible failures, ensuring errors are handled upfront. This eliminates runtime surprises and strengthens the API contract, fixing the type safety gap.

Conclusion

Functional programming and monads, via kotlin-result, transform error handling into something explicit, type-safe, and composable. They tackle hidden control flow with clear paths, resolve the checked/unchecked mess with typed errors, simplify resource management, and restore type safety—all while boosting readability and maintainability.

So, when should you go for Result or try-catch?

  • Use Result:

    • For expected failures in normal flow: validation errors, network timeouts, or parsing issues. These are business logic concerns where you want fine-grained control and explicit outcomes in your code.
    • When designing APIs or libraries, to give users predictable, exception-free contracts.
    • In functional pipelines, where chaining operations with error propagation feels natural.

  • Use try-catch (Exceptions):

    • For unexpected, unrecoverable errors: null dereferences, file corruption, or logic bugs. These signal something’s broken, not a routine failure, and are best caught at a higher level (e.g., app-wide handlers).
    • When working with legacy code or external APIs that throw exceptions, and wrapping them in Result isn’t practical yet.
    • For centralized recovery, like logging crashes or restarting a service, where granular handling isn’t the goal.

Think of it this way: Result is for errors you plan to handle locally, while exceptions are for errors you escalate or crash on. Roman Elizarov’s take on Kotlin’s exception philosophy (link) echoes this: exceptions are for the exceptional, not the everyday.

References