Skip to content
0:00 / 0:00

#kotlin#errorhandling#uniontypes

Rich Errors in Kotlin | Michail Zarečenskij

Kotlin by JetBrains

100K subscribers • 61 videos on Hallway

YouTube
  • Recommended by 2 people: 2 in engineering communities.
  • Presented by Michail Zarečenskij, Kotlin compiler developer

Advanced. Deep dive for people who know the field.

20K views1 year ago2 recommendations

Programming languagesSoftware designKotlinLanguage design and type systemsFunctional programming

Michail Zarečenskij explores a proposal to generalize Kotlin's nullability model into restricted union types for rich error handling.

Get ready for what’s next — join us at KotlinConf 2026 👉 kotl.in/conf26-ytd Recording brought to you by American Express. americanexpress.io/kotlin-jobs Kotlin's nullability model is one of its core features. In this talk, we’ll explore how this model can be generalized to restricted union types specifically designed for handling error cases. Additionally, we’ll discuss how errors can currently be represented in Kotlin, covering approaches such as nullable types, exceptions, sealed hierarchies, and Result-like classes.

Why it's here

2 people recommend this

What people say. Recommended for understanding the future of error handling and union types in Kotlin.

Moments people linked to

u/mcmacker4in r/Kotlin • Recommends

On “STOP throwing Errors! Raise them instead”

Check out this video about rich errors, which is a proposal to have something similar to arrow built into kotlin, but please do me a favor and watch it until the end. At first i thought the same as you. These are just checked exceptions with a different name. But one of kotlin's main filosofies is writing the least boilerplate possible, and this becomes clear in the video only after the basics of rich errors are established. After that, you will see the difference between checked exceptions and rich errors.

u/Radiokot1in r/Kotlin • Recommends

On “Better ways to handle exceptions in Kotlin: runCatching and Result<T>”

Watch: [video

u/PentakilIin r/Kotlin • Mentions

On “From Exceptions to Rich Errors: Rethinking Error Handling in Kotlin I Michail Zarečenskij”

by default it'll be exposed as a `java.lang.Object` and they've thought about using compiler plugins to generate methods returning `Optional<>` or `Result<>` instead link to this video
3View on Reddit