Kotlin's rich errors: Native, typed errors without exceptions • Hacker News Board

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

#31

Post by pjmlp » Fri, Jan 23, 2026, 10:27 PM UTC

zaphirplane wrote: post #27

pjmlp wrote: post #7

Earlier quoted context omitted.

That is always the gotcha with guest languages. C++ cannot get away from C, Typescript cannot get away from JavaScript, and so forth.

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.

C++ started as a C macro preprocessor, designed to work as C in UNIX, and by CFront 2.0 there was already too much compatibility to throw away.

Ts is basically a linter, everything else is JS.

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

#32

Post by thesz » Fri, Jan 23, 2026, 10:37 PM UTC

spankalee wrote: post #22

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 and Result 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 uns…

  > 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 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 of yours is a Result (e, t) in Haskell, which is very distinct from Result e t (Either e t).

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

#33

Post by pianoben » Fri, Jan 23, 2026, 10:38 PM UTC

pjmlp wrote: post #28

pianoben wrote: post #23

Earlier quoted context omitted.

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 brin…

Lies, damm lies. They cherry pick whatever they feel like from OpenJDK. And even though Oracle was right, given that Android is Google's J++, in this case they had better luck than Microsoft. They don't take more from OpenJDK because then their anti-Java narrative doesn't work out. But there is some schadenfreund, to keep Kotlin compatibility story relevant they are nonetheless obligated to keep up with is mostly use…

Maybe I'm wrong about the state of Java in Android today - it's been a few years since I did that work full-time. But I do remember when Kotlin broke on to the scene in 2015, and most of us were thrilled to finally move beyond Java 7! The embrace of a non-Java language was grassroots and genuine; Google's adoption came several years later.

J++ though, now that is a blast from the past! I think I still have a J# book from my student days, somewhere :)

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

#34

Post by mamcx » Fri, Jan 23, 2026, 10:38 PM UTC

spankalee wrote: post #22

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 and Result 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 uns…

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...

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

#35

Post by tadfisher » Fri, Jan 23, 2026, 10:48 PM UTC

pjmlp wrote: post #8

simon_void wrote: post #2

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…

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.

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 is not quite the same as rich errors which explicitly are not representable by user types.

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

#36

Post by spankalee » Fri, Jan 23, 2026, 10:48 PM UTC

hutao wrote: post #30

spankalee wrote: post #22

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 and Result 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 uns…

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/…

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.

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

#37

Post by tadfisher » Fri, Jan 23, 2026, 10:51 PM UTC

dingi wrote: post #14

simon_void wrote: post #2

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…

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.

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.

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

#38

Post by spankalee » Fri, Jan 23, 2026, 11:33 PM UTC

thesz wrote: post #32

spankalee wrote: post #22

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 and Result 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 uns…

> 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 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…

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)`.

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

#39

Post by hutao » Sat, Jan 24, 2026, 12:23 AM UTC

spankalee wrote: post #38

thesz wrote: post #32

Earlier quoted context omitted.

> 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 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…

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)`.

The `Either a b` type in Haskell is equivalent to the `Result` type in other languages. The only difference is in the naming: "Result" semantically implies error handling, while "Either" implies a more general usage as the alternative between two options. Either and Result are the binary sum type (the disjoint union between two types).

In Haskell, Either is defined as

    data Either a b = Left a | Right b

Note that in Haskell, type parameters are lowercase. Source code: https://gitlab.haskell.org/ghc/ghc/-/blob/3f5e8d80b32063d265...

Contrast the definition of the Result type in Swift:

    public enum Result {
      /// A success, storing a `Success` value.
      case success(Success)

      /// A failure, storing a `Failure` value.
      case failure(Failure)
    }

Source code: https://github.com/swiftlang/swift/blob/256ff127c93d7e59a75f...

I'm not sure what the parent commenter meant when they claimed that "Result of yours is a Result (e, t) in Haskell." In Haskell, `(e, t)` would be the pair type (the binary product type).

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

#40

Post by andrekandre » Sat, Jan 24, 2026, 2:30 AM UTC

pianoben wrote: post #33

pjmlp wrote: post #28

Earlier quoted context omitted.

Lies, damm lies. They cherry pick whatever they feel like from OpenJDK. And even though Oracle was right, given that Android is Google's J++, in this case they had better luck than Microsoft. They don't take more from OpenJDK because then their anti-Java narrative doesn't work out. But there is some schadenfreund, to keep Kotlin compatibility story relevant they are nonetheless obligated to keep up with is mostly use…

Maybe I'm wrong about the state of Java in Android today - it's been a few years since I did that work full-time. But I do remember when Kotlin broke on to the scene in 2015, and most of us were thrilled to finally move beyond Java 7! The embrace of a non-Java language was grassroots and genuine; Google's adoption came several years later. J++ though, now that is a blast from the past! I think I still have a J# book…

  > But I do remember when Kotlin broke on to the scene in 2015, and most of us were thrilled to finally move beyond Java 7!

n=1 but i was there with android studio v0.01 (or thereabouts) using kotlin for a production app cause i was so sick of old-java + eclipse... google was asleep at the wheele imo and android development would be nowhere near where it is today without jetbrains