A Proposed Evolution for Kotlin's Error Handling

The Kotlin language has long been praised for its pragmatic approach to solving common programming challenges, particularly with its robust null-safety system. However, the domain of recoverable, predictable errors has remained an area where developers rely on a patchwork of patterns rather than a first-class language feature. The "Rich Errors" proposal, also known as Error Union Types, is a significant design initiative aimed at addressing this gap.

This study explores the motivation and rationale behind this proposal. We will analyze the shortcomings of existing error-handling patterns in Kotlin and examine how the proposed Rich Errors feature aims to unify them into a more expressive, type-safe, and ergonomic system.

The State of Error Handling in Kotlin: A Spectrum of Patterns

The proposal begins by acknowledging that Kotlin, by inheriting from the JVM, started with exceptions. However, it deliberately omitted Java's controversial "checked exceptions," leaving developers to handle errors through three primary patterns, each with its own trade-offs.

1. Exceptions for Unrecoverable Errors: Kotlin's philosophy reserves exceptions for unrecoverable errors (programmer bugs, failed preconditions) and for non-local control flow in frameworks. For example, require(userName.isNotBlank()) rightfully throws an exception because a blank username is a violation of the function's contract. The caller is not expected to "recover" from this; it's a bug that needs to be fixed. This use case is considered well-served and is not the target of the new proposal.

2. Nullable Types (T?) for Simple Failures: The most common and idiomatic way to handle simple, recoverable failures is by returning null. Functions like String.toIntOrNull() and List<T>.firstOrNull() are prime examples. This pattern integrates beautifully with Kotlin's null-safety operators (?., ?:).