Member-only story

Stop Using Kotlin’s Result in Your Application Code!

A deep dive into why Result is not ideal for handling errors in application code and how Either offers a better approach.

Mirco | VerboseMode.dev
Javarevisited
Published in
5 min readFeb 9, 2025

Photo by Kind and Curious on Unsplash

A couple of days ago, I had a discussion about Kotlin’s Result type vs. arrow-kt's Either. There are upsides and downsides to both, but I am a big fan of Either over Result, mainly because I think the design of Result comes with some flaws. Before we discuss these flaws, let’s take a step back and look at Result and why one might want to use it.

Understanding Result

Result is a class from the Kotlin standard library. The KDoc states that it is:

A discriminated union that encapsulates a successful outcome with a value of type T or a failure with an arbitrary Throwable exception.

In other words, we can use Result in places where we would throw an exception, with the difference that returning a Result will not change the control flow as a thrown exception does.

Take a look at this example:

fun unsafeParseInt(str: String): Int {
return str.toInt() // This throws NumberFormatException for invalid input
}

fun main() {
val numbers = listOf("1", "2", "abc", "4")
val parsedNumbers =…

Create an account to read the full story.

The author made this story available to Medium members only.
If you’re new to Medium, create a new account to read this story on us.

Or, continue in mobile web

Already have an account? Sign in

Javarevisited
Javarevisited

Published in Javarevisited

A humble place to learn Java and Programming better.

Mirco | VerboseMode.dev
Mirco | VerboseMode.dev

Written by Mirco | VerboseMode.dev

Backend Developer. My opinions are my own.

Responses (3)

What are your thoughts?