Evaluating Rich Errors: use cases from existing projects

[zarechenskiy]

The document evaluates how Rich Errors (KEEP-0462) could be used in a few projects today, analyzing both declaration and use sites. It comes somewhat late: some of this was already analyzed in the first version of the Rich Errors proposal (link), but we now have more concrete examples. Plus, since the design has changed quite a lot, we had to revisit how the feature could be applied in practice and now publish our findings.

Feel free to challenge the document or share your own examples of where Rich Errors could (or couldn’t) help in your domain.

Read the full design notes: Evaluating Rich Errors in the Wild

[CLOVIS-AI]

Errors-as-values handling techniques are rarely unified even inside one project. And different projects use a different subset of all possible options. A developer moving between modules (or even companies) re-learns the local error dialect each time. Rich Errors make the dialect part of the language.

I'd like to point out that this doesn't solve the problem. C++ is the worst example of this, where the same language effectively has different dialects in different teams, even though everything is available out of the box to all of them.

[CLOVIS-AI]

Thanks for making this study! The 'callsite' sections specifically are very interesting to me, and I felt they were missing in the initial KEEP.

It looks like the conclusion of this study is that the operators are essentially never used? There are seven examples with ifError and only one with |.. Almost all examples handle the errors immediately and don't propagate them, which I don't find representative of the codebases I've worked on, so I'm quite surprised.

[zarechenskiy]

It looks like the conclusion of this study is that the operators are essentially never used?

That's actually true. So far, we've seen only a few cases for |., which may be a good sign as less will be needed in the language

[CLOVIS-AI]

Did you find any example where errors are propagated?

[zarechenskiy]

We had some in earlier studies, but not that many. I'll look into concrete examples. I suspect it's partially because today, with kotlin.Result and similar wrappers, we don't provide flatMap and similar functionality. And in general, to make this pattern convenient today, we'd need some sort of monadic comprehension syntax, so people might naturally avoid propagating errors this way

[mikehearn]

I looked at the code myself and in many cases the error objects are propagated, wrapped and transformed - often losing the causal chain.

[rnett]

Do you have plans to look at some non-android (e.g. server side, maybe spring) projects too?

[zarechenskiy]

Here, it’s the Space project, which is our internal project, so it’s not particularly useful for a public study. If we talk about Spring, the framework there mostly nudges you towards exceptions, so, except perhaps for some common logic, we don’t see much of a domain-specific error-as-value pattern there

[rnett]

For readability purposes we may also introduce something like typealias Ok = Unit to have signatures fun checkNoteFieldsResponse(note: Note): Ok | InvalidNoteFields

As a human, I like this, but I think it's the kind of thing that would trip up AI agents.

[CLOVIS-AI]

I'm personally not a fan, Unit is pretty clear in this role and having yet another name requires more learning and bikeshedding.

[rnett]

I think the clarification about how rich errors are more meant to replace sealed result hierarchies than all exceptions is very helpful and important, and I hope something along those lines makes it into the docs when the feature is released.

[mikehearn]

I think the main question is just why encourage developers to use this pattern, which from the use cases cited doesn't seem better than exceptions and is often clearly worse e.g. there's lots of manual wrapping and propagating going on, and in most cases a simple try/catch block would be equally or more concise.

The only real benefit seems to be restoring checking in the type system, but a new take on checked exceptions in Kotlin (which I'd love to see) would fix that too.In fact the very first example cited, Signal's NetworkResult class, states specifically that it only exists because Kotlin doesn't have checked exceptions!

The final example also shows the risks of this approach. That an operation is in progress isn't actually an error, so error types are being abused as a general union type in that case. But it's not called out as an abuse, in fact it's called out as a good way to use the feature.

[kyay10]

IMO, automatic propagation is better served by something like Arrow's Raise. It really is that "new take on checked exceptions", and would get even better with lifetimes.

Rich errors provide a great alternative to the pre-existing "sealed Result type" pattern. They can also help replace some uses of exceptions/nulls (e.g. instead of throwing an exception, toInt could be toInt(): Int | ParseError)
That's already a great niche for them to live in.

That an operation is in progress isn't actually an error

Maybe I'm stretching the meaning of "error" a bit, but I think "in progress" is actually a great use for this! It's different from the "success" path and it needs special handling (e.g. trying again). You can easily see someone using null for this purpose, no? So rich errors fit in nicely here.