Chapters
Chapters

Chapters

Hide chapters

Functional Programming in Kotlin by Tutorials

First Edition · Android 12 · Kotlin 1.6 · IntelliJ IDEA 2022

Before You Begin

Section 0: 5 chapters
Show chapters Hide chapters

Section I: Functional Programming Fundamentals

Section 1: 8 chapters
Show chapters Hide chapters

Section II: Data Types & Typeclasses

Section 2: 5 chapters
Show chapters Hide chapters

Section III: Functional Programming in Practice

Section 3: 7 chapters
Show chapters Hide chapters

Appendix

Section 4: 13 chapters
Show chapters Hide chapters

14. Error Handling With Functional Programming
Written by Massimo Carli

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

In the first two sections of this book, you learned everything you need to know about pure functions. You learned that a pure function has a body that’s referentially transparent and, maybe more importantly, doesn’t have side effects. A side effect is a “disturbance” of the world external to the function, making the function difficult to test. Exceptions are a very common example of a side effect. A function containing code that throws an exception isn’t pure and must be fixed if you want to use all the concepts you’ve learned so far.

In this chapter, you’ll learn how to handle exceptions — and errors in general — using a functional programming approach. You’ll start with a very simple example before exploring the solution Kotlin provides using the Result<T> data type. In particular, you’ll learn:

  • What exception handling means.
  • How to handle exceptions as side effects.
  • How to “purify” functions that throw exceptions.
  • How to use Optional<T> in functions with exceptions.
  • How to use Either<E, T> to handle exceptions in a functional way.
  • How to implement a ResultAp<E, T> monad.
  • How to compose functions that can throw exceptions.
  • What the Kotlin Result<T> data type is and how to use it in your application.

You’ll learn all this with a practical example that allows you to fetch and parse some content from the internet. This is the same code you’ll use in the RayTV app, which allows you to access data about your favorite TV shows.

Note: You’ll use the RayTV app in the following chapters as well.

You’ll also have the chance for some fun with a few exercises.

Exception handling

Note: Feel free to skip this section if you already have a clear understanding of what exceptions are and why they exist.

Every application is the implementation of a set of use cases in code. A use case is a way you describe how a specific user can interact with a system. Figure 14.1 is an example of a use case describing the scenario when a RayTV app user wants to search for their favorite TV show.

Figure 14.1: RayTV search use case
Figure 14.1: RayTV search use case

This use case diagram says two main things:

  1. Who can access the specific feature of the app. In this case, it’s the RayTV app user.
  2. What the RayTV app can do. In this case, it allows the user to search for a TV show by name.

Usually, you also describe the use case in words by writing a document like this:

Use Case: Search TV shows
Actors: RayTV app
Prerequisites: The user starts the RayTV app.
Steps:
1. The user selects the search option.
2. The app shows the keyboard.
3. The user inputs some text.
4. The user taps the search button.
5. The app accesses the search service and fetches the results.
6. The app displays the results in a list.
Final state: The app displays the results of the search.

It describes what the user can do and how the system reacts. This use case is very specific, though. It describes when everything works fine. You call this the happy path or principal use case. Many things can go wrong. For instance, a network error can happen, or the search simply doesn’t produce any results. In this case, you describe these situations using alternative use cases, like the one in Figure 14.2:

Figure 14.2: RayTV alternative use case
Figure 14.2: RayTV alternative use case

In this case, you describe the scenario as a use case that shows what happens when the happy path isn’t followed. In this case, the search doesn’t produce any result. Usually, you describe this scenario with a document like this:

Use Case: Handle empty results
Actors: RayTV app
Prerequisites: A TV show search produced no results.  
Steps:
1. The app displays a message that says the search has produced no results.
Final state: The app waits for action from the user.

This is all good, but what do use cases have to do with errors and exceptions? Well, exceptions aren’t always bad things. They’re just a way programming languages represent alternative scenarios. In general, you have three different types of situations:

  • Errors: These represent cases when something really wrong happens. They aren’t recoverable, and the developer should understand the cause and solve it. Typical examples are VirtualMachineException, IOError or AssertionError.
  • Checked exceptions: This is the type of exception that describes alternative use cases. If you have a connection error, you should somehow handle it. A user entering an invalid credit card number is a common occurrence, so it’s something your code should be prepared to handle. These are checked because in some programming languages, like Java, you have to explicitly declare them in the signature of the method that can throw them.
  • Unchecked exceptions: RuntimeException is another way to describe this type of exception because it can happen at runtime. A typical one is NullPointerException, which is thrown when you access a member of an object through a null reference. Although you can recover from a RuntimeException, they usually describe bugs you should eventually fix.

Kotlin doesn’t have checked exceptions, which means you don’t need to declare them as part of the function throwing them. This doesn’t mean you shouldn’t handle the exception. Kotlin represents them with classes extending Throwable and still provides you the try-catch-finally expression. So what’s the best way to handle exceptions controlling the flow of your program? Now that you have a solid functional programming background, you know that exceptions are side effects. How can you use what you’ve learned to handle exceptions elegantly and efficiently? Monads, of course! :]

Note: It’s interesting to remember how the type of the following expression is Nothing:

 throw IOException("Something bad happens")

Remembering the analogy between types and sets, you know that Nothing is a subtype of any other type. This means the value you return when you throw an exception has a type compatible with the return type of the function itself.

Handling exception strategies

In Chapter 13, “Understanding Monads”, you learned that functions throwing exceptions are impure. An exception changes the world outside the body of a function. In the same chapter, you also learned how to purify a function by changing the side effect to be part of the return type. The same works for exceptions, and you can achieve this using different data types depending on the strategy you want to adopt. Different strategies include:

Some preparation

Before describing the different ways of handling exceptions, it’s useful to look at some of the classes you find in the material for this chapter. These are the classes you initially find in the fp_kotlin_cap14 project, and you’ll see them again in the RayTV app in their final state. The RayTV app will allow you to search for a TV show and display some of the show’s information on the screen. This is basically the use case in Figure 14.1.

Waxatu 19.7: WyBluxYawjfug ufg NhZvifNemwap ubuv podpt
Zimaba 88.6: HdFxabMagskiq edp MsMtulTunyuw igel hahrn

Handling errors with Optional<T>

The RayTV app sends a request to the server, gets some JSON back, parses it and displays the result to the user. This is the happy path, but many things can go wrong. Both TvShowFetcher::fetch and TvShowParser::parse can fail.

Handling errors with Either<E, T>

The Optional<T> data type is very useful, but it just tells you if you have a response; it doesn’t tell you what the error is if something goes wrong. In this case, a data type like Either<E, T> can help you. In lib, you’ll find Either.kt, which contains all the code you implemented in Chapter 9, “Data Types”. To see how to use it, just add the following code to ShowSearchService.kt, this time in the either sub-package:

Applicative functor

In the previous section, you learned how to handle exceptions using Optional<T> and Either<E, T> data types following a fail fast approach that stops the execution flow at the first exception. With Either<E, T>, you also get what’s wrong. In Chapter 9, “Data Types”, you learned that Either<A, B> is a bifunctor, which is an algebraic data type representing the addition of two types, A and B. In the previous use case, you used Left<E> to represent the error case and Right<T> for the success case.

ResultAp<E, T> as an applicative functor

One of the most important things you’ve learned in this book is that functions are values, which is why you can implement higher-order functions. This also means that T in ResultAp<E, T> can be a function type like (T) -> T. So, what would the meaning be of a function ap with the following signature?

Applicative functors and semigroups

As mentioned, the previous code doesn’t allow you to get all the validation errors, only the first. Open ValidationSemigroup.kt and add the following code:

The Kotlin Result<T> data type

As mentioned earlier, the Kotlin standard library has a Result<T> type that is similar to ResultAp<E, T>, which you implemented earlier.

Result<T> as a functor

To prove that Result<T> is a functor, you should verify the functor laws, and in particular, that:

Result<T> as a monad

As mentioned at the end of the previous section, the Kotlin Result<T> data type doesn’t have a flatMap. What happens, then, if you need to compose a function of type (A) -> Result<B> with a function of type (B) -> Result<C>? Well, in Chapter 13, “Understanding Monads”, you learned how to handle this case with a generic data type M<A>. It’s time to do the same for Result<T>.

Using Result<T> as a monad

Open ShowSearchService.kt in result and add the following code:

Meet the RayTV app

In the first part of the chapter, you learned how to handle exceptions in a functional way. You implemented two functions for fetching and parsing some data about TV shows using APIs provided by TVmaze.

Cayodi 30.0: MezKQ ehd
Dexeva 43.5: JimYG ikn

Waqexi 78.6: XJ ttij coubjt wigipct
Qobuzo 87.0: BG pbik vuutts vopihfk

Xinado 89.4: DL wmeb boteazt
Sexuye 26.1: NJ cmuj bonoimq

Kipijo 56.0: HagKD elyam peprefu
Taqapa 62.9: MijRP eqfob qonquko

Key points

  • Error handling is a fundamental part of any software application.
  • Many programming languages model errors using exceptions.
  • Exceptions are a classic example of side effects.
  • For exceptions, you can use the same process you used for other impure functions: Make the side effect a part of the result type.
  • You can use Optional<T> and Either<E, T> to model functions throwing exceptions.
  • Applicative functors and semigroups are useful in the case of multiple validations.
  • The Kotlin standard library provides the Result<T> data type.
  • Result<T> is a functor but not a monad.
  • You can make Result<T> a monad by following the same process you used in Chapter 13, “Understanding Monads”.

Where to go from here?

Congratulations! In this chapter, you had the chance to apply all the principles and concepts you learned in the first two parts of the book in a real example. In the next chapter, you’ll learn everything you need to know about state.

13. Understanding Monads
15. Managing State
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now