Stop throwing exceptions!

Now that I got your attention, let me specify what this article actually wants to say: STOP THROWING EXCEPTIONS!

In the world of Kotlin, there are some great ways to catch exceptions. The most reasonable way is to catch using a try/catch block:

try {
    something()
} catch (exception: Exception) {
    println(exception)
}

The nice thing, is that try/catch in Kotlin is an expression, so you can actually return useful data from either the try or the catch.
Kotlin also has some great support for catching exceptions in flows:

flowOf(“Some”, “values”).catch { println(it) }

And finally, there is the way to wrap a call in a Result object:

runCatching {
    something()
}

The only thing Kotlin is not particularly great at, is knowing what piece of code may throw an exception. That is, as we all know, because Kotlin does not support checked exceptions. I know what you are thinking: I am smart! I know exactly what piece of my code throws an exception. I am the greatest catcher in all the lands, I shall catch them all! For you I have a great exercise: Which of the 2 following functions throws an exception?

fun function1() {
    println(getSomeInformation())
}

fun function2() {
    println(getSomeOtherInformation())
}

Place your bets! I am afraid to tell you: We will never know which one throws an exception, and above all, we should not care. The lack of checked exceptions in Kotlin is not a bug: It is actually a feature.
A feature I advise you to actually use during whatever development journey you are on right now, regardless of language. Rust users probably don’t see the point of this whole article, as they already live in the fairy tale land without runtime exceptions.

But why?

It is simple: catching stuff is ugly. It makes me want to not handle things, things that I should handle. Even if you use an archaic language like Java, you should not rely on wrapping your code in try/catch blocks. Also in Java, try/catch is not an expression and therefore we cannot properly return values from it.

It hinders readability as you are actually forcing yourself into some kind of hidden error throwing context that only your IDE and compiler may figure out. It is not nice to rely on the red squiggly lines in IntelliJ to figure out whether something may or may not crash during compilation or runtime. For VIM users: IntelliJ is an IDE that actually helps you write code in a fast and efficient way, unlike whatever you think is efficient inside your little terminal with your shortcuts.

So what should we do?

I shall repeat the title once more: we should stop throwing exceptions! Of course with the exception when we want the program to actually crash. Which more often than not, we do not want to happen. As a matter of fact, lots of time is spend to avoid a program from crashing.

Lets take a step back and look at the problem from a distance: Every application is in essence a fancy wrapper around a database. In the end, we want to propagate a result from this database: It is either the value that we want, or we failed to get the value from the database. It does not matter through which hoops we have to jump to actually get the data from the database somewhere over the pacific ocean, into a cache on a phone and displayed on a screen. We can define these 2 options perfectly fine in actual code without relying on magic.

So enough foreplay, here comes the code! Or at least, one way to do it. As in every problem that 100’s of people already solved before (and probably better than) me, this shall not be the first or the best approach. But I like this approach, I wrote this article, so I’m gonna go ahead with it.
Let’s put ourselves in the shoes of an Android developer. Boy, those are some dirty shoes. Now lets have a view model. First we catch stuff in the good old fashioned way, later on we shall improve it:

class MyViewModel(
 private val fetchSomeStuffUseCase: FetchSomeStuffUseCase,
 private val someMapper: SomeMapper
): ViewModel() {

    val viewState = MutableStateFlow<ViewState>(LoadingState)

    init {
        viewModelScope.launch {
            try {
                val newState = someMapper.map(fetchSomeStuffUseCase.run())
                viewState.update { newState }
            }.catch(e: Exception) {
                println(e)
            }
        }
    }

}

As any proper mobile engineer, we blatantly ignore anything that is not on the happy path. Lets fix that up, because I care:

class MyViewModel(
    private val fetchSomeStuffUseCase: FetchSomeStuffUseCase,
    private val someMapper: SomeMapper
): ViewModel() {
    val viewState = MutableStateFlow<ViewState>(LoadingState)

    init {
        viewModelScope.launch {
            val newState = try {
                someMapper.map(fetchSomeStuffUseCase.run())
            }.catch(e: Exception) {
                println(e)
                ErrorState
            }
            viewState.update { newState}
        }
    }
}

The code in this case is understandable, but if you would omit the try/catch, it will run just fine (until it run’nt). Also, take a look at the following contrived example:

class FetchSomeSafeStuffUseCase(
    private val fetchSomeDangerousStuffUseCase: FetchSomeDangerousStuffUseCase,
) {

    suspend fun run(): Stuff? = try {
        fetchSomeDangerousStuffUseCase.run()
    } catch (e: Exception) {
         println(e)
         println("Failed to fetch stuff, returning null!")
         null
    }

}

Please point to the doctor where it hurts. If it doesn’t hurt, get off the morphine, because congratulations, you just caught the CancellationException that is used to stop the coroutine from running upon cancellation. So, how do we fix these things?

Result result result!

Kotlin comes with a built-in Result class. Now, you may think “Oh that is just a sealed class with a Success and Failure sub classes”. But boy, are you wrong! It is actually a value class, previously called an inline class, which means in more cases than not you will not have the overhead of allocating a wrapper class around your values. Which in the case you have a million objects, is a nice bonus.

Now the actual nice thing, is that the Kotlin standard library provides some great extension functions out of the box with this Result class. You can getOrNull() it, getOrElse {} it, you can map {} it, you can onSuccess {} and onFailure{} it, you can recover {} it and just like your laundry: you can fold {} it! Ironically, I fold Results just as often as I fold my laundry. The only thing that misses, in my honest opinion, is a flatMap {} method. Let me explain it a bit for the people that also have a hangover: The problem when you map a result to another result, is that you will have a result within a result:

fun example(
    initialResult: Result<Something>,
): Result<Result<Other>> = initialResult.map { something -> 
    getAnotherResultBasedOnSomething(something) 
}

This is, as you may guess undesirable. Especially when we want to chain actions. Instead, we simply wish to flatten it and have a simpler result object. We shall now write a simple flatMap {} extension function for the result object:

inline fun <T, R> Result<T>.flatMap(
    transform: (T) -> Result<R>,
): Result<R> {
    contract {
        callsInPlace(transform, InvocationKind.AT_MOST_ONCE)
    }
    val value = getOrElse { 
        return failure(it) 
    }
    return transform(value) 
    // Could be a oneliner, but split it up for dramatic purposes:
    // return transform(getOrElse { return failure(it) })
}

So the basics are set up, now let us rewrite the view model using Result objects, and take off your socks because you are about to be underwhelmed!

class MyViewModel(
    private val fetchSomeStuff: FetchSomeStuffUseCase,
    private val mapper: SomeMapper
): ViewModel() {
    
    val viewState = MutableStateFlow<ViewState>(LoadingState)

    init {
        viewModelScope.launch {
            val newState = fetchSomeStuff.run().map(mapper::map).getOrElse {
                println(it)
                ErrorState
            }
            viewState.update { newState }
        }
    }
}

Now the important part here, is that we can map things easily, and the getOrElse {} will get the value in case of success, or else return the result in the block you pass to it. As I said, you may be underwhelmed, you may well as be excited, it is hard for me to judge as we are in separate locations and I probably never met you. However, why would we handle the failure handling in the viewModel? We could simply pass the whole Result down to the mapper and let that handle the failures as well!

class MyViewModel(
    private val fetchSomeStuff: FetchSomeStuffUseCase,
    private val mapper: SomeMapper
): ViewModel() {
    
    val viewState = MutableStateFlow<ViewState>(LoadingState)

    init {
        viewModelScope.launch {
            val newState = fetchSomeStuff.run().map(mapper::map)
            viewState.update { newState }
        }
    }
}

Now our view model is very clean and easy to test! The mapping of the result is now abstracted away to the mapper as well, and therefore easier to test! So lets go a step further and take a look into our use case:

class FetchSomeStuffUseCase(
    private val fetchLoggedInUserUseCase: FetchLoggedInUserUseCase,
    private val fetchSomeSecretUseCase: FetchSomeSecretUseCase,
    private val someRepository: SomeRepository,
) {

    suspend fun run(): Result<Something> = fetchLoggedInUserUseCase.run()
        .flatMap { user -> fetchSomeSecretUseCase.run(user) }
        .flatMap { secret -> someRepository.fetchSomethingWithSecret(secret) }
}

This, in my humble opinion, is extremely readable. No magic happening here, we simply fetch a user, upon success we use it to fetch the secret, with which we can fetch something. Now I want to mention the best of it all: Inside our view model and inside our use cases, we actually use the same kind of logic! Triggering something and then mapping it it is a pattern that even the kids can enjoy. But wait, there is more! Lets do the thing where we have a repository and get our data from either memory, database or network. Now the standard library offers us an extension function called Result.recover {} where we have a block that will recover the result on a failure:

fun recoverExample(initialResult: Result<String>): Result<String>
    = initialResult.recover { “Will be returned if initialResult is failure” }

You can see here, that whenever initialResult is a failure, it will recover and be successful, even though it will stay a result object. However, I of course do not wish to give it a simple value, I wish it to take in another result object, similar to the amazing flatMap {} we created earlier. To be fair, I should say “I created earlier” because I do feel I did most of the work there. So, like the flatMap {}, I made a similar function called flatRecover {}, because somehow naming things is the hardest part in this world, that can try to recover a failure with another result object.

class SomeRepository(
    private val memoryCache: MemoryCache,
    private val database: Database,
    private val network: FancyShmancyNetwork,
) {
 
    suspend fun fetchSomethingWithSecret(
        secret: String,
    ): Result<Something> = memoryCache.get(secret).flatRecover {
        database.get(secret).flatRecover {
            network.get(secret).onSuccess { something ->
                database.set(secret, something)
            }
        }.onSuccess { stuff ->
            memoryCache.set(secret, something)
        }
    }
}

OMG. It is like functional programming and awesomeness had a baby. For my hungover friends, the steps are simple: Fetch something from memory first, if it is there, then that is it. You and the code part ways and never see each other again. But, upon failing to fetch something from the memory cache, the database is questioned about the whereabouts of the data. If the database has the value, it can directly return it. Once again, if the database fails to deliver, the network stack is invoked to complete the challenge. Upon success, the database is updated. In term, if either the fetch from the database or the network was successful, the memory will also be updated, which allows for easy access in the future, which you may or may not have guessed.

The map {}, flatMap {} and flatRecover {} can be at the core of the flow of any form of data. One pattern to rule them all, as any kind of data can be retrieved in this way. You need to get a user location? Great, lets chain that mofo up:

suspend fun run(): Result<Location>
    = checkLocationPermissionUseCase.run().flatMap { /* unit -> */
        checkLocationServicesEnabledUseCase.run()
    }.flatMap { /* unit -> */
        fetchUserLocation.run()
    }

So result is the only thing I need?

Yes. And no. Do what you want, just stop throwing exceptions! We talked about this… So now, lest us discuss the possible downsides to this approach:

As the result object is a value class with quite some inner magic to hold either an exception or a value, we cannot do pattern matching:

when(result) {
    is Success /* Does not exist */ -> doStuff()
    is Failure /* Does not exist */ -> doFailureStuff()
}

Also, you cannot define the type of exception. I want to mention Arrow here, as that is a library that many Kotlin users are hyping because of its Either type, where you can specify if it is either this or a certain type of exception. I welcome you to have a look there!
Personally: a lot of data in mobile applications you get through the network stack. It may fail with whatever exception, like IOException, or maybe some error because you were using a faulty vpn to secretly search for gifts for your spouses, who knows? All I know, is that more often than not my error handling will have an ‘else’ branch regardless of how good I can predict any possible failures.

Another downside is when you have any existing addiction to throwing and catching stuff, you are just used to it. Once you overcome it, you will be fine. In my transitioning phase, as in moving from Java to Kotlin, I tried, and failed, to be the greatest catcher in all the land. I am very happy to have moved onto using Result objects. You still will need to catch things, but only on the outskirts of your code where your app is interacting with other libraries, which may or may not throw exceptions, depending on the gratitude of the author. My advice: For any code that may throw something, directly wrap it in a runCatching {} block at the source. This in turn will return a Result object, which you can safely propagate throughout your app.

I am sure your language has a way of dealing with results properly, instead of throwing stuff all around the place like an angry toddler.

All in all, I had fun finally putting my thoughts on paper. And with paper, I mean notepad on my laptop. I wish you all a happy day, and a happy tomorrow.