Kotlin's rich errors: Native, typed errors without exceptions

https://cekrem.github.io/posts/kotlin-rich-errors-elm-union-types/

by todsacerdoti • 6 months ago

61 82 6 months ago

cekrem.github.io

simon_void2• 6 months ago

Rich Errors look promising to me, but what about interop with Java? What will the return-type of a function be on the Java side be, if the return type on Kotlin side is: Int | ParseError | SomeOtherError?

Background: unions aren't restricted to one normal type and one error type, but to one normal type and any number of error types, so this can't be modelled as syntactic sugar on top of an implicit Either/Result type, can it??

pianoben3• 6 months ago

what about interop with Java?

From the proposal discussion[0], the runtime representation on the JVM will just be `Object`.

[0] https://github.com/Kotlin/KEEP/discussions/447#discussioncom...

ubertaco• 6 months ago

Oof. That's pretty gross: just throw away all typesafety?

A `Result<T, E>` return type is way better.

This feels like it'll be viewed like Java's `Date` class: a mistake to be avoided.

pjmlp9• 6 months ago

Kotlin folks seem to mostly care about Java as bootstrap to their own ecosystem.

The anti-Java bias, against the platform that made it possible in first place and got JetBrains a business, is quite strong on Android, fostered by the team own attitude usually using legacy Java samples vs Kotlin.

pianoben3• 6 months ago

Android folks have good reason to have anti-Java bias. Their bias, as it happens, is against old Java, which they are constrained to use as fallout from the Oracle lawsuits of yore. Kotlin breathed new life into Android in a meaningful way.

On backend teams, I've not personally encountered much anti-JVM bias - people seem to love the platform, but not necessarily the language.

(yes I know there's desugaring that brings a little bit of contemporary Java to Android by compiling new constructs into older bytecode, but it's piecemeal and not a general solution)

tadfisher2• 6 months ago

This is needlessly divisive. JetBrains does not owe two-way interop to the Java ecosystem.

There are many Kotlin features that do not have clean interop with Java; Compose, coroutines, and value classes come to mind. And it turns out that this mostly benefits Java, because these features are not built with the kind of engineering rigor that Java language features enjoy, and some of these features would behave way better with support in the VM anyway.

Where it makes sense, they are already moving closer to Java/JVM-native feature implementations; for example, data classes already have two-way support via records, and value classes are almost there (waiting on Valhalla GA).

Besides, wouldn't you want this stuff represented in the Java type system anyway? Otherwise you get the Lombok problem, where you have this build dependency that refuses to go away and becomes a de facto part of the language. Result<T, E> is not quite the same as rich errors which explicitly are not representable by user types.

dingi• 6 months ago

They only care about Java -> Kotlin integration. Not the other way around. It has been like this for a long time. Looks like an extractive relationship to me to be frank.

tadfisher2• 6 months ago

Anyone who is writing Kotlin libraries to be consumed by Java code is going to either avoid this feature or write wrapper functions for better Java interop. There is no reason to accuse language designers of lock-in by designing features that don't have a clear equivalent on every possible foreign interop target.

rhdunn2• 6 months ago

Kotlin does have interop with Java, but is limited by either the features not existing in Java (non-nullable types) or behave differently in Java (records, etc.).

You have to explicitly annotate that a Kotlin data class is a Java record due to the limitations Java has on records compared to data classes [1]. This is similar to adding nullable/not-null annotations in Java that are mapped to Kotlin's nullable/non-nullable types.

Where there is a clean 1-1 mapping and you are targeting the appropriate version of Java, the Kotlin compiler will emit the appropriate Java bytecode.

[1] https://kotlinlang.org/docs/jvm-records.html#declare-records...

rileymichael• 6 months ago

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

https://www.youtube.com/watch?v=IUrA3mDSWZQ&t=2626s

simon_void2• 6 months ago

thank you for the link to the talk! I actually witnessed the talk live, but must have completely missed this or simply forgot that this was answered :D

cekrem• 6 months ago

The Java interop compromise is probably the biggest weakness of the proposal - it works beautifully within Kotlin but degrades at boundaries. This is similar to how Kotlin's nullable types (String?) become platform types in Java.

I think it's good nonetheless to add stuff to Kotlin that won't translate 1:1 to Java, both because Java is evolving but also because Kotlin is used in "Native" (non-JVM) contexts as well (not extensively, but hopefully that'll change).

pjmlp9• 6 months ago

That is always the gotcha with guest languages.

C++ cannot get away from C, Typescript cannot get away from JavaScript, and so forth.

zaphirplane3• 6 months ago

That is more interoperability than guest language situation. I don’t think c++ is a c guest. Ts has a different approach to the js self.

wiseowise5• 6 months ago

The ship has sailed the moment Kotlin believed it could break away from the JVM ecosystem. And for a good reason, it would be just slowly consumed by the progress of Java.

armchairhacker• 6 months ago

These remind me of checked exceptions in Java. Ironically, Kotlin removed checked exceptions because they tend to be annoying more than useful: there's no clear guideline to whether an exception is checked or unchecked, some functions like IO and reflection have them while others don't, they're verbose especially when closures are involved, and lots of functions simply catch and rethrow checked exceptions in unchecked exceptions.

Which leads me to: why is Kotlin implementing this in a non-JVM compatible way, instead of introducing checked exceptions with better language support? All the problems stated above can be avoided while keeping the core idea of checked exceptions, which seems to be the same as this proposal.

From the GitHub discussion, I see this comment (https://github.com/Kotlin/KEEP/discussions/447#discussioncom...):

The difference between checked exceptions from java and error unions in this proposal is how they are treated. Checked exceptions are exceptions and always interrupt the flow of execution. On the other hand, errors in this proposal are values and can be passed around as values or intentionally ignored or even aggregated enabling the ability to use them in async and awaitAll etc.

But is this a real difference or something that can be emulated mostly syntactically and no deeper than Kotlin's other features (e.g. nullables, getters and setters)? Checked exceptions are also values, and errors can be caught (then ignored or aggregated) but usually interrupt the flow of execution and get propagated like exceptions.

sirwhinesalot• 6 months ago

Exceptions are cheap on the happy path and super expensive on the error path.

Checked exceptions only make sense for errors that are relatively common (i.e., they aren't really exceptional), which calls for a different implementation entirely where both the happy path and the error path have around the same cost.

This is what modern languages like Rust and Go do as well (and I think Swift as well though don't quote me on that) where only actually exceptional situations (like accessing an array out of bounds) trigger stack unwinding. Rust and Go call these panics but they are implemented like exceptions.

Other errors are just values. They have no special treatment besides syntax sugar. They are a return value like any other and have the same cost. As they aren't exceptional (you need to check them for a reason), it makes no sense to use the exception handling mechanism for them which has massively skewed costs.

HendrikHensen4• 6 months ago

Rust and Go call these panics but they are implemented like exceptions.

I don't know about Rust, but a very important difference between Java exceptions and Go panics, is that a Go panic kills the entirely process (unless recovered), whereas a Java exception only terminates the thread (unless caught).

It's a little off-topic, but I wanted to clarify that for passer-bys who might not know.

tester756• 6 months ago

Exceptions are cheap on the happy path and super expensive on the error path.

Depends on the software, huh.

elcritch• 6 months ago

Result or Error types may just be normal values, but they add overhead to the code as well when they’re ubiquitous.

Once they’re the standard error method then case every function has to intertwine branching for errors paths vs normal paths. Often the compiler has to generate unique code or functions to handle each instance of the Result type. Both add to code size and branching size, etc.

vips7L3• 6 months ago

Exceptions are cheap. Stack trace collection is the expensive part; if you make use of checked exceptions for domain errors you can just turn that off if you hit a performance problem.

loglog2• 6 months ago

The plain Java equivalent of the proposed semantics would be a type system extension similar to JSpecify: @Result(ok=Ok.class, error={Checked1.class, Error2.class}) Object function() combined with enough restrictions on the usages of results of such methods (e.g., only allow consuming the results in an instanceof pattern matcher; not even switch would work due to impossibility of exhaustiveness checking).

The one feature that the proposed Kotlin error types share with Java checked exceptions is that they can be collected in unions. However, the union feature for checked exceptions is pretty much useless without the ability to define higher order functions that are generic over such unions, which is why checked exceptions fell out of favor with the spread of functional APIs in Java 8.

ajrouvoet• 6 months ago

This last point is the key observation.

Tyr422• 6 months ago

I think bridging this syntax onto legacy checked exceptions from java would make a lot of sense.

guelo• 6 months ago

Because Kotlin took a dumb turn about 5 years ago and decided that multiplatform was their future instead of the jvm (because they felt threatened by React Native and Flutter on Android). Point being, they don't want to tie themselves to the jvm anymore. The language has been stagnant for years as they've had to reimplement tons of java libraries and also shoehorn the extreme complications of multiplatform into the awful gradle build system. All for this dumb dream that has gone no where.

yk09123• 6 months ago

Thank god they did, they are in a really good place now

wiseowise5• 6 months ago

Because Kotlin took a dumb turn about 5 years ago and decided that multiplatform was their future instead of the jvm (because they felt threatened by React Native and Flutter on Android).

It’s because JB intends to make money on their investment, unlike the other two. This is the reason why Kotlin ecosystem is a half baked mess – JB tries to artificially replicate all successful ecosystems without having a community.

mr7uca• 6 months ago

You can argue the tooling is still immature... but kmp really has been taking off since cmp has gone stable on ios. The kmp library ecosystem is even getting quite large. Also, kmp has very distinct advantages over React Native and Flutter, they didn't just copy-paste from RN or Flutter.

esafak• 6 months ago

Slated for release in 2.4 this summer. Track in https://youtrack.jetbrains.com/issue/KT-68296

ixtli• 6 months ago

This is nice, and I develop often in Kotlin, but none of this will really achieve what people want so long as any line can possibly throw a runtime exception.

loglog2• 6 months ago

I think that the problems with unchecked exceptions are due to the simultaneous presence of both checked and unchecked exceptions. The designers must have thought that checked exceptions would be the rule, but left an escape hatch.

If there were no checked exceptions to begin with, people might have thought about making the Java compiler (and later language server) infer all possible exception types in a method for us (as effect systems do). One could then have static analysis tools checking that only certain exception types escape a method, giving back checked exceptions without the type and syntax level bifurcation.

On the other hand, if all exceptions were checked, they would inevitably have had to implement generic checked exception types, ironically leading to the same outcome.

jpalepu33• 6 months ago

The discussion around checked vs unchecked exceptions always comes down to ergonomics vs safety.

Having worked extensively with Node.js (callback hell, then Promises), I appreciate how error-as-value patterns force you to think about failure cases at every step. But the reality is most developers don't - they either:

1. Ignore the error case entirely (leading to silent failures) 2. Bubble everything up with generic error handling 3. Write defensive code that becomes unreadable

Rust's Result<T, E> with the ? operator found a sweet spot - you have to acknowledge errors exist, but the syntax doesn't make it painful. The key innovation is making the happy path concise while forcing acknowledgment of errors.

For Kotlin specifically, I'm curious how this interops with existing Java libraries that throw exceptions. That's always the challenge with these proposals - they work great in greenfield code but break down at library boundaries.

The real question: does this make developers write better error handling code, or just more verbose code? I'm cautiously optimistic.

HendrikHensen4• 6 months ago

The biggest problem is that people treat it as a dichotomy: either exceptions or error values. But that's a false dichotomy.

There would be real value in a language which would have both.

Error values are perfect for un-exceptional errors, e.g. some states of a business logic. The name that the user entered is invalid, some record is missing from the database, the user's country is not supported. Cases that are part of the business domain and that _must_ be handled, and therefore explicitly modeled.

Then there is the grey area of errors that one might expect (so not truly exceptional) but are not related to the business logic. These could be for example network timeouts, unexpected HTTP errors (like 503), etc. For those, there is often no explicit handling in the domain that makes sense. So it's convenient to just throw an exception, let it automatically "bubble" to the highest level (e.g. the HTTP controller) and just return some generic error (such as HTTP 500).

There are also truly exceptional cases, that you really shouldn't encounter in your program, such as null-dereferences, invalid array index access, division by zero, etc. These indicate a bug in the code (and might be introduced explicitly with assert-style checks). The program is in an unknown, compromised state, so there's really nothing left to do than throw an exception or panic. An error value makes very little sense in this case.

I often have the discussion with friends, why a division operator, or an array access, doesn't return a `Result` type in nice languages such as Rust? Surely, if they care about error values, then each operation that can fail, must return a `Result` rather than panic (throw an exception). It is an interesting through experiment at least.

Tyr422• 6 months ago

Sounds like checked and unchecked exceptions.

I mean, this could be a syntax wrapper for java checked exceptions right?

Those are isomorphic to Result<_, Err> in that you must handle or propagate the error. The syntax is different, sure.

josephg2• 6 months ago

why a division operator, or an array access, doesn't return a `Result` type in nice languages such as Rust?

Rust has standard library functions to do this, if you want. arr.get(index) returns an Option. Integer types have .checked_div for panic-free divide. Float already doesn’t panic on an invalid division - it just returns NaN or Infinity.

frumplestlatz• 6 months ago

It's absolutely a true dichotomy. If unchecked exceptions exist, all code must be carefully written to be exception-safe, and the compiler is not going to help you at all.

Of course it's convenient to be able to ignore error paths when you're writing code. It's also a lot less convenient when those error paths cause unexpected runtime failures and data corruption in production.

A preference for unchecked exceptions is one of my most basic litmus tests for whether a developer prioritizes thinking deeply about invariants and fully modeling system behavior. Those that don't, write buggy code.

hackthemack• 6 months ago

Similar thoughts.

One thing I notice in enterprise java software that I have to reed through and update, is that too many times, every developer just wraps everything in an exception. I do not have vast insight into all java code, everywhere, but in my little corner of the world, it sure looks like laziness when I have to dig through some ancient java code base.

spankalee4• 6 months ago

Does anyone know of a great write up on exceptions vs union or either typed returns?

I'm building a new language, somewhat similar to TypeScript in some ways, and so far I have exceptions and try/catch expressions, but also Optional<T> and Result<T, E> types.

I'm familiar and used to exceptions, so I included them so at least near-fatal errors (ie, actually exceptional) could be caught at high levels in the stack. But I'm unsure if there's a strong argument that resonates with me yet that the language shouldn't have exceptions at all. Arguments that exceptions are untyped can be solved with things like checked exceptions, and I do find Go-style code to be quite verbose.

What's the best current reading on this?

hutao5• 6 months ago

One of the most thorough articles on error handling in programming language design that I've read is this one: https://joeduffyblog.com/2016/02/07/the-error-model/. It was written by Joe Duffy, who worked on Microsoft's experimental Midori language.

Another relevant article is Robert Nystrom's "What Color is Your Function?": https://journal.stuffwithstuff.com/2015/02/01/what-color-is-... This article is about async/await, but the same principles apply to error handling. This article uses colors as an analogy, but is really about monads.

Both IO and exceptions can be denoted as a monad. What this means is that a function inside the programming language, A -> B, can actually be denoted by a mathematical function of the signature [[A]] -> M [[B]], for some monad M. For example, if we are dealing with the exception monad, M would be _ + Exception.

A language such as Java implicitly executes in the IO + exception monad. However, the monad can also be exposed to the programmer as an ordinary data type, which is what Haskell does. When people talk about the tradeoff of exceptions versus Result<T, E>, or the tradeoff between preemptive concurrency and async/await, they are really talking about the tradeoff between making the monad implicit or explicit. (A language where all functions may throw is like one where all functions implicitly return Result<T, E>. A language where all functions may be preempted is like one where all functions are implicitly async, and all function calls are implicitly await points.)

The theoretical technique of using monads to model the implicit effects of a programming language was pioneered by Eugenio Moggi, and the idea of making them explicit to the programmer was pioneered by Philip Wadler.

Something else to think about is how monads stack. For example, how would you handle functions that are both async/await and throw exceptions? Does the answer change when the monad is implicit (e.g. throwing exceptions) or explicit (e.g. returning a result)?

spankalee4• 6 months ago

That Midori article looks great, I'll give that a closer read. I actually used to work with Bob, and am familiar with the (wonderful!) function color article.

I think my biggest question might be addressed in the Midori article: with things like bounds checks and checked casts you already have exceptions (or panics), so should you have a way to capture them anywhere on the stack? Are they recoverable in some programs? So should you have try/catch even if you try to make most errors return values?

Another set of questions I have is around reified stacks. Once you have features like generators and async functions, and can switch stacks around, you're most of the way to resumable exceptions. I don't yet fully grok how code as the resume site is supposed to deal with a resume, but maybe resumable exceptions are a reason to keep them.

thesz3• 6 months ago

  > But I'm unsure if there's a strong argument that resonates with me yet that the language shouldn't have exceptions at all.

Result <E, T> is the type Either e t in Haskell. And Either is a Monad: https://hackage-content.haskell.org/package/base-4.22.0.0/do...

This means you can have a computation inside Either e monad (notice missing result type) which can occasionally produce an exception, and these exceptions are checked (Either String cannot produce SNAFU-type exceptions, only textual descriptions of what was wrong).

So, if you are developing your language, please consider embedding it in Haskell first. That would allow you to experiment with different type representations, at the very least: Result <e, t> of yours is a Result (e, t) in Haskell, which is very distinct from Result e t (Either e t).

spankalee4• 6 months ago

I'm targeting only WASM at the moment. I wish I could get into Haskell, but I just can't read it. I really can't parse what's going on with types like `Result e t (Either e t)`.

mamcx• 6 months ago

Alternatively look at https://dlang.org/articles/exception-safe.html.

The problem of mixing paradigms is that get confusing. Ideally all is represented equally (ie: All errors are `Result`) but is the handling that get confusing. Each option is a totally different control flow.

And it not compose (even if you use effects ) (and I mean ergonomically*) so you need to pick wich one to make first class

P.D: I'm pretty certain about the "not compose, in practice", I have seen lots of options and none looks nice, but open to corrections!

P.D.2: It should also consider the things on the dlang handling, and the midori article...

antonvs• 6 months ago

Both Rust and Go are good examples of modern languages with no exceptions.

Not coincidentally, both provide a panic mechanism, which is intended for failures that are either unrecoverable or at least not locally recoverable. Both languages allow you to "catch" panics, but this mechanism is constrained and impractical to use for normal error handling. Instead, it's used to e.g. prevent a service from crashing if individual requests fail unrecoverably.

The point is that these languages both demonstrate a simple design for exception-free languages.

(Although Rust's approach is better in several ways, partly because it has a better type system.)

noelwelsh3• 6 months ago

The innovation here is, I think, the use of union types. The problem with errors as standard algebraic data types (ADTs) is you end up with lots of boilerplate to transform from one ADT to another, as errors propagate through the system. With union types (as found in Typescript and Scala 3) you can add and remove types from the union in an ad-hoc manner. IIRC Elm doesn't have union types, so I think the blog post is a bit inaccurate.

brabel3• 6 months ago

Of course Elm has union types, it’s like one of its main features!

https://guide.elm-lang.org/types/custom_types.html

noelwelsh3• 6 months ago

I mean union types in the programming language theory sense, not in the "we called this language feature union types" sense. Elm's union types are algebraic data types (ADTs). Union types in the PLT sense are what Typescript has. The main difference is that an ADT must be declared upfront, whilst a union type can be constructed in an ad-hoc manner based on whatever types are used together at a particular point in the program.

Kotlin's rich errors: Native, typed errors without exceptions

Related Stories