Typesafe Error Handling in Kotlin

https://kotlin.christmas/2019/17

by veiset • 7 years ago

62 34 7 years ago

RivieraKid4• 7 years ago

Honestly, I prefer to have the option of using checked exceptions, it's often leads to better readability than using Result. This is my main issue with Kotlin.

cies2• 7 years ago

Really? Exceptions introduce some sort of magic in control flow, it is simply less explicit. It may come in handy, but I rather use it as a final resort than as a way to return different types (I've seen exceptions being used in Java for non-error cases I guess because sum-types (aka tagged unions) are not available).

Having this (together with pattern matching) as the-way-to-do-errors in Kotlin is one of the main reasons I feel it fixes what Java cannot (easily) fix.

Can you articulate how it increases readability?

Razengan• 7 years ago

Do you mean like Swift? (which also has a Result type)

https://docs.swift.org/swift-book/LanguageGuide/ErrorHandlin...

RivieraKid4• 7 years ago

Yes. Swift and Julia re my favourite languages.

ragnese4• 7 years ago

I feel like I'm the only crazy person who thinks checked exceptions are better than unchecked exceptions. I've read all the arguments against them and they just don't resonate with me. "Oh. So you think it's okay that a dependency's method changed to throw a new exception, but you don't want to have to change your code? Sounds super lazy and risky to me..." When your dependency's logic changes, yours probably needs to, as well.

What really drives me nuts is when the same person shits on checked exceptions and then advocates for using a monadic return value. They're completely isomorphic. The only difference is in how it reads.

lmm2• 7 years ago

The difference is that monadic result types work properly with generics. You can't really use checked exceptions generically at all (simplest example: you can't pass a function that throws a checked exception as a callback function, unless you write multiple overloads of any function that takes a callback), which really limits your ability to reuse code.

lenkite• 7 years ago

Java is the only language that has checked exceptions AFAIK.

Checked exceptions just lead to interface pollution. You really don't know what type of exception can be thrown by an implementation of a facade when you are defining the facade. And so then you are forced to define a InterfaceOperationException and then force all callers to wrap their exceptions in this type. Even if you use an implementation that is exception-free, you are forced to catch.

Painful and elaborate ceremony for very little gain. Usually exception handling is centralised at a few places in the code. Catching exceptions at these areas and boundaries is the best place instead of littering handler code all over the code base.

Oracle has realised that checked exceptions are a mistake. None of the java functional interfaces declare checked exceptions. If your operation throws a checked exception, it cannot be used as a convenient method reference lambda. It does not decay into a standard functional interface. This alone is an ultra critical-strike against checked exceptions.

If a condition is so important that you need to declare it as a checked exception, it generally indicates it should have been be a return type or your functional granularity is large. And normal types, unlike exception types, are well-suited to generics.

saghm• 7 years ago

What really drives me nuts is when the same person shits on checked exceptions and then advocates for using a monadic return value. They're completely isomorphic. The only difference is in how it reads.

Is that true? I was under the impression that annotating a certain type of exception being thrown doesn't prevent other (i.e. unchecked) exception types from being thrown from a method. If that's true, then that's a pretty significant different between monadic returns and checked exceptions; in the former case, returning an unknown error type leads to a compiler error, but in the latter, it leads to a crash at runtime.

joostdevries2• 7 years ago

When designing C# Anders Heljsberg decided against following Java's checked exceptions. You can find his argument against in the interview from 2003 https://www.artima.com/intv/handcuffs.html

jbverschoor• 7 years ago

Ah right another thing copied from swift.

cies2• 7 years ago

I think a lot of languages implemented this before Swift did. Some MLs (among them OCaml), Haskell, Reason, Elm, Rust.

So crediting Swift for this is not fair.

Sharlin• 7 years ago

The fact that you were introduced to concept X by language Y rarely means that X was invented by Y.

UK-Al05• 7 years ago

It's actually a fairly old method, that's recently gained popularity as functional programming interest increases.

vmchale4• 7 years ago

I think monadic do comes from Haskell and its ancestors.

vmchale4• 7 years ago

I'm pretty sure monadic error handling came from some ML

exdsq• 7 years ago

I’ve finally reached the age where I was using something before a language that ‘copied’ it even existed!

This was around in Haskell before Swift existed.

benol• 7 years ago

It's worth pointing out that Kotlin's standard library contains a type called `Result` with a slightly different API. Also a function called `runCatching`[1] that uses it.

[1] https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/run-catc...

manojlds• 7 years ago

What are these .Christmas TLDs? Seeing those crop up and only makes sense at this time of the year right?

outadoc• 7 years ago

https://blogg.bekk.no/introducing-bekk-christmas-ad01660ccad...

BiteCode_dev• 7 years ago

I kinda like it, although here it's clearly an marketing attempt and probably also an SEO move of some sort.

Still, it's "python xmas!" all year long would be a nice theme for a blog :)

UserIsUnused• 7 years ago

Why not just use sealed classes for your given use-case rather than a generic result? If you want to do generic why not go full Either?

mrkeen• 7 years ago

Maybe the people that realise that are the people who self-select into a language where Result and Either are just implementation details and should be hidden behind F[_] or similar.

joostdevries2• 7 years ago

The monadic approach to exceptions like it's done here has the downside of having to encode all your business logic in maps and flatmaps. All the intermediary functions will have to return Try. And all the Try values have to combined into one. That type fidding code feels like cruft that doesn't add much value.

And I say that having developed in Scala for years and years.

Of course there's still sometimes when you want processing of other items to proceed, even though this one has failed. And that's where Try is really essential. So that's where we use it only: at the topmost level.

It's only at that top level that we wrap the call in a Try. And that works rather well.

One reason to do it like this is that we want to leverage the design philosophy of Kotlin. And not be writing Scala or Haskell in Kotlin ). And Kotlins philosophy when it comes to exceptions turns out to be: exceptions. Which is apparent in Kotlin coroutines, channels and flows.

) that's also why we try to stay away from Arrow

ragnese4• 7 years ago

Definitely fair points. I do feel like I'm swimming upstream even when I'm using the built in Result class in Kotlin.

Truth is, I rather be writing Rust, but I need the JVM sometimes. ;)

vmchale4• 7 years ago

All the intermediary functions will have to return Try.

That's the advantage of the monadic/functorial approach: they don't!

ragnese4• 7 years ago

I'm a little confused by something. I wouldn't have expected his/her example code to compile:

  fun divide(dividend: Int, divisor: Int): Try<Int, String> =
      when (divisor) {
          0 -> Try.Err("Cannot divide by zero!")
          else -> Try.Ok(dividend / divisor)
      }

The first branch of `when` is of type `Try<Nothing, String>`, the second branch is `Try<Int, Nothing>`, and the return value is supposed to be `Try<Int, String>`. None of those line up...

How is that possible? Does the compiler do some magic for the `Nothing` type? The definition looks pretty damn simple:

  public class Nothing private constructor()

greiskul• 7 years ago

It's not possible in Kotlin to have an instance of Nothing, and the compiler does some magic for the Nothing type, in that it can be converted to any other type in the system (so it's like the opposite of the Any type). This allow code patterns like:

''' val personName = person.name ?: throw IllegalArgumentException("Name required") '''

Where the type of personName is now String, cause if name was null it would throw an exception (and the type of a throw expression is Nothing).

lmm2• 7 years ago

Nothing is (magically) a subtype of every type, and Try is covariant in both its parameters (Kotlin has its own non-standard terminology for variance that I can't remember, but what it really means is covariant).

mamcx• 7 years ago

One of the most use-full things of Rust is to have a clear "conversion" trait:

https://doc.rust-lang.org/std/convert/trait.From.html

This is my #1 thing with rust.

Is a stroke of genius to have a clear API for make conversions.

vmchale4• 7 years ago

Is there any writeup of the theory behind this? I'm particularly interested in type inference.

killercup• 7 years ago

The RFC for adding `?` to the language might be a good start: https://rust-lang.github.io/rfcs/0243-trait-based-exception-...

Typesafe Error Handling in Kotlin

Related Stories