It seems that you bunch too many error-handling issues into the single bucket. There cannot be a single “error handling facility that meets all the needs and suits everyone”. Let’s take your example. If you have errors that need to be tracked and shown in UI then you clearly do not need any kind of stack trace (since you are not going to show it to the user), so it is a good case for use of sealed classes: they are explicit and composable.

Easy stack unwinding is also not a big problem— with Kotlin and its inline functions you can design a very convenient DSL that fits your domain. It is not going to as concise as ? in Rust, but I’m sure you can leave with something more verbose, but clear and explicit, as .orElse { return it } .

Written by

Project Lead for the Kotlin Programming Language @JetBrains

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store