Rich Errors

[e2e4b6b7]

This discussion is dedicated to the new Rich Errors proposal. The current full text of the proposal is available here.

This proposal focuses primarily on design details. The previous proposal, which covers the motivation behind the feature, is available here.

[whyoleg]

I'm curious: do we really need to have a new Value type at all?

Based on the document, it feels that we could safely replace it with Any \ Error and everything will work smoothly.
At one point, the document says: "For example, is checks for Value are compiled as inverted checks against Error:"

fun foo(v: Any) {
  if (v is Value) { // at runtime: `v !is Error`
  }
}

So this already implies that Value is some magic class, and so it should be possible to do an explicit check against Error:

fun foo(v: Any) {
  if (v !is Error) {
    // v is of type `Any \ Error` here
  }
}

And this case is also covered in negative smart-casting section:

fun <T : Any> foo(v: T) {
    if (v is Error1) return
    // v is smart-casted to T \ Error1
}

As well as other examples already show, this notation will be possible. (at the middle of this section)

fun <T : Any? \ NoSuchElement> List<T>.firstOrError(): T | NoSuchElement

I understand that by doing this, we will stumble upon a problem where we can't do (Any \ Error) | SomeOtherError under the current rules. But if we just add one more rule that says it's allowed (only for Error), so it's just transformed into Any | SomeOtherError, will everything still work fine? Meaning, that (Any \ Error1) | Error2 is still not allowed.

Yes, this will make Error even more specific, but at least we will have only one "special" type.
Or maybe I've missed another fundamental issue with it?

---

I don't mind having Value class really, apart from, of course, it's a very-very generic name and clashes with value class (in both Java and Kotlin), but for me, it seems that without it, the whole model looks a bit easier to understand.

[e2e4b6b7]

Yes, Value could be represented in different forms: as typealias Value = Any \ Error, or simply as an inlined Any \ Error. However, it would still be some composite type that differs from common negation.

The special handling around \ Error will probably be needed for smart casts anyway. So the proposed option might simplify not only the mental model, but also the actual model.

The original intention behind Value was to simplify the places where this type is needed. If there are not many places where using Value is both useful and idiomatically correct, we might replace it with special rules for \ Error instead.

[whyoleg]

Thanks!

The original intention behind Value was to simplify the places where this type is needed. If there are not many places where using Value is both useful and idiomatically correct, we might replace it with special rules for \ Error instead.

Do you have some more examples of when it might be really useful to use Value instead of Any \ Error?
So far, I've checked the KEEP, and the only places where Value is used in examples are:

1. if (v is Value) to get smartcast - in which case, the inverse variant if (v !is Error) reads in the same way (or even better, IMO).
2. stdlib functions like ifError or throwIfError.

In all other cases, it seems that for checks and smartcasts, it's preferred to check against an error (e.g., if(x is HttpError)) rather than the value type itself. So it feels like Value here contradicts everything else.

I also started to think about when I will need to add more functions where Any \ Error will be used in generic types, and it seems that all of them will be super generic - like ifError/throwIfError, and so potentially, there will not be a lot of them (if any). :)
In most cases, it feels that you would want to exclude some specific Error subtype (like NotFound).
So I would really be glad to hear more examples, where this "verbosity" (or "explicitness") of Any \ Error is a problem.

[basiliscus]

Is the following example - a valid usage of the new concept?

	error object AutoGenerate

	fun <T> trySet(key: StorageKey<T>, value: T, version: Long | AutoGenerate = AutoGenerate): Boolean {
		...
	}

If so, shouldn't we use a more general term instead of "error"?

[IRus]

No, it's not. For this case you'll rather need nullable value or sealed type.

Nearly every language feature can be misused or outright abused. Your point of generality would be correct only if people would often misuse rich errors to emulate union types.

[kyay10]

I don't see why it's not valid? AutoGenerate is representing the lack of value here, while still allowing you to pass it explicitly so you get the default value. I understand the feature is called errors. I don't see how this differs a lot from the "internal error used for function implementation" use case. Both ends up using an "error" to instead represent state (usually a lack of value), and both benefit from being able to handle that error.

I think this is effectively a DSL, and in DSLs, almost anything goes in terms of pushing language features to their limit

[IRus]

@kyay10

is representing the lack of value here

What else representing it already in the language?

I don't see how this differs a lot from the "internal error used for function implementation" use case

fun verifyVersion(version:  Long | AutoGenerate):  Long | AutoGenerate | InvalidVersion = ... 

So while you can hack around, semantics and language would not be on your side

[CC007]

I think that the two things that are confused here are 'the state you have' vs 'the behavior you're expecting'.

In the case of an error type, you provide or act on a state, which can either be a value state or an error state. Think for instance:

error object NotFound
Person.getById(id: Uuid): Person | NotFound = ...

@kyay10 's example on the other hand is based on an expected behavior. From that perspective, they'd probably like to be able to do the following:

error object Failure
error object AutoGenerateId  // not really an error
Person.createNew(name: String, address: Address, id: Uuid | AutoGenerateId = AutoGenerateId): Success | Failure = ...

I do see how that perspective could be valid, where AutoGenerate is basically a named sentinel (like in Python) that better describes what you want it to do, something that a nullable type doesn't tell you unless you look at the docs. It also would prevent you from having to write a wrapper sealed interface:

sealed interface NewPersonId
object AutoGenerateId implements NewPersonId
data class ExistingId(id: Uuid) implements NewPersonId

Person.createNew(name: String, address: Address, id: NewPersonId = AutoGenerateId): Success | Failure = ...

The fact that you'd have to explicitly define that sealed interface has advantages, but also drawbacks, like being more verbose, where Uuid | AutoGenerateId would suffice.

On the other hand, you could also argue that you'd want the interface to be more based on 'the state you have', rather than 'the behavior you're expecting'. That could be an implementation detail that should be left to the function.

error object Failure
error object Unknown
Person.createNew(name: String, address: Address, id: Uuid | Unknown = Unknown): Success | Failure = ...

Where createNew is responsible for deciding what to do when the id is unknown. It could auto-generate one, it could decide to quietly not create a new person, it could return a failure, it could decide to log a warning, etc. That's up to the specific implementation to decide.

I could see arguments for both sides though.

[rnett]

On the other side, bang-bang operator !! and elvis operator ?: will not have any counterparts for error unions. The main reason for it is that we do not want to extend the existing operators with error handling support due to backward-compatibility concerns. The details could be found in the section Why existing nullability operators cannot be reused.

Now that we are using | for error operators, this seems less valid. What about introducing |: and |! (or &) operators?

[Amejonah1200]

I'm all for using funny emojis as syntax, but I see an issue with using | specifically: in other languages it is used for pipeing: bash, functional langs, etc.

[e2e4b6b7]

What about introducing |:

Currently, we do not see a significant advantage over .ifError {}, especially since we still think that |: would need to introduce a variable for the error, so it would look something like |: {}.

|! (or &) operators?

I do not understand, what operators do you propose here

I see an issue with using | specifically: in other languages it is used for pipeing: bash, functional langs, etc.

Piping usually means taking the successful result of the left-hand side and feeding it into a specific position on the right-hand side: for example, stdout to stdin, a return value to the first argument, and so on. If there is no successful result, the chain does not continue.

The |. operator follows the same general idea: it takes the successful result of the left-hand side, uses it as the receiver of the right-hand call, and stops the chain when the left-hand side is an error.

In that sense, the meanings are quite close.

[CC007]

If .ifError {} is sufficient and therefore wouldn't require |:, then why did Kotlin decide to introduce ?: if something like .ifNull {} would suffice? The reason is programming ergonomics through providing syntactic sugar.

The same argument holds for |! as the counterpart for !!:
myVal!! throws a NullPointerException when myVal is null
myVal|! could throw a KotlinErrorException when myVal is an error.

If you know that a certain variable can't hold an error (like when a library didn't correctly specify for certain inputs that the result is never an error) or you are using it in a test and you'd want the test to fail anyway if it does, it would allow you to do the following:

... // do something that would insert a row with id 5
val expectedId = 5
val expectedEntity = getById(expectedId)|!
expectedEntity.foo.bar shouldBe "foo bar"

This also makes it more clear WHERE the error could occur, compared to:

... // do something that would insert a row with id 5
val expectedId = 5
val expectedEntity = getById(expectedId)
expectedEntity|.foo|.bar shouldBe "foo bar"

Here it's not clear if foo itself could also result in an error, unless you look at the definition of Entity.foo.

[CC007]

An example for where |: could be useful:

error object Failure
error object Unknown

// some code somewhere from a library or something
class Person(id: Uuid, name: String, address: Address)
object EntityManager {
   ...
   fun store(newPerson: Person): Boolean
}
fun callSomeExternalServiceForGeneratingANewUuid(): Uuid | Failure = ...

// your code
fun Person.createNew(name: String, address: Address, id: Uuid | Unknown = Unknown): Success | Failure {
    val newId = id |: callSomeExternalServiceForGeneratingANewUuid() |: Uuid.random()
    val newPerson = Person(newId, name, address)
    if(!EntityManager.store(newPerson)) return Failure
    return Success
}

Here, callSomeExternalServiceForGeneratingANewUuid() could itself return an error, so without |: you'd have to use a nested ifError {}. Also, you couldn't easily put the random Uuid as a default value.

[rnett]

To prevent this case from happening, we prohibit merging of errors from different sources. In the previous example, AccessDenied might come from two different sources: through chain short-circuiting from resolveUser and as a result of medicalRecord. For this reason, this code is rejected as a compilation error.

I very much dislike making this a compiler error. There are many cases where it is entirely valid to merge errors from different sources. For example, it might be coming from the same underlying service used in different calls. The issue happens when errors are more general than their sources, and whether that's the case or not is a design decision of a particular codebase, not something that can or should be enforced at a language level.

[e2e4b6b7]

We share this concern, but we would like to better understand how problematic it is in practice: how often it occurs and how difficult it is to work around.

This restriction provides some safety at the cost of flexibility. So this is a tradeoff, and we would like to evaluate during the experimental phase whether it is worth keeping.

It is easy to remove this restriction later, but almost impossible to introduce it.

[CLOVIS-AI]

From all the examples that have been given so far, it seems to me that there are two clear groups of errors:

• NetworkError, Unauthenticated and such: it doesn't matter which call it comes from,
• NotFound, Unauthorized and such: it very much does matter which call it comes from, that's crucial information to know what recovery actions can be taken.

It seems to me that the desirability of merging errors can be statically decided for any error.

What about keeping the default behavior of forbidding error merging, but having some kind of marker to allow it? For example some kind of marker interface:

error object NotFound

error class Unauthenticated(
    val realm: String,
) : MergeableError  // TODO: find a better name

Here, NotFound would behave exactly as in this KEEP. However, the compiler would allow merging Unauthenticated from different origins.

[Sporking]

I have quite a bit of code that is written using what is essentially a result type, that represents an object of type T or a string error message that will be displayed to the user, like so:

sealed class Outcome<out T> {
    data class Ok<T>(val value: T) : Outcome<T>()
    data class Err(val errMsg: String) : Outcome<Nothing>()

    inline fun onErr(action: (Err) -> Nothing): T = when (this) {
        is Ok -> value
        is Err -> action(this)
    }

    inline fun <U> mapValue(func: (T) -> U): Outcome<U> = when (this) {
        is Ok -> Ok(func(value))
        is Err -> this
    }
    //...
}

so if I have to do "a" and then "b" and then "c" and then error out if any of them failed, I would do:

fun doSomething() : Outcome<Int> {
    //...
    
    // The functions a, b, and c might return either values or error messages.
    // If any of them return an error message, return it before proceeding further.
    val x = a().mapValue { it.b() }.mapValue{ it.c() }.onErr { return it }

    //...

    // If we got this far, we succeeded.
    return Outcome.Ok(42)
}

Note that in cases like these, I am using the same error type (a string containing an error message) for each of the a, b, and c functions, because I don't really care what failed (the error message explains that to the user if they care), but only that something did. All I am going to do with the error is to display it to the user anyway as an explanation for what they tried to do didn't happen, so there is no real reason to distinguish between different types of errors in this code: one error type works for everything.

It would be rather awkward and inconvenient to have to come up with a separate error type for the possible failure of each of the a, b, and c functions, especially if I have, say, a d function that calls several of them and also needs to be used. I don't see a reason for this to be required by the proposal, and it would forbid some kinds of programming structures such as the one I currently use quite widely, and prevent that code from easily being modified to use this new feature.

I very much don't like that the current proposal forbids merging identical errors from different sources. I think this should be left up to the programmer, not up to the framework, and I consider it a weakness of the current proposal.

[rnett]

To prevent this, we disallow non-disjoint error unions in the function signatures. As a result, the declaration of firstOrError would be rejected.

I like this at first glance, but as the subsequent examples show, it effectively colors generics, and I don't think it's worth that. It's very common, IMO, to just declare unbounded type params where you just need basic parameterization - I know my code is littered with them. This design means that, for example, you wouldn't be able to call any error-returning generic function on them. The declaration would need to essentially opt-in to any errors that could be used, which may not be known or even accessible there.

I don't have a great alternative solution, but I do not think requiring every type parameter declare what error types is can work with up front is a workable solution.

[kyay10]

I don't think I understood this restriction the same way you do. My understanding is that unions that show up in function signature will have to be disjoint, so you'll need to declare \ for errors you explicitly use, or for cancelling out other error type parameters.
For example, you can merge two errors like so (assuming you also want the individual error types just to make this more interesting):

fun <T1: T, T2: T, E1: Error, E2: Error \ E1, EShared: Error \ E1 \ E2, T: Value?> choose(boolean: Boolean, first: T1 | E1 | EShared, second: T2 | E2 | EShared): T | E1 | E2 | EShared

Of course, it can be made simpler, while still keeping the exact typing for first and second:

fun <T1: T, T2: T, E1: E, E2: E, E: Error, T: Value?> choose(boolean: Boolean, first: T1 | E1, second: T2 | E2): T | E

It doesn't even need \!

[e2e4b6b7]

The expected behavior is not to opt in to all errors used inside the function, but only to the errors exposed in its signature, and to write generic functions in a safe way that works correctly for all possible input values.

We already see a similar issue with nulls: T? is sometimes used inside a function body while forgetting that null may already be included in T, which can lead to unexpected incorrect behavior for nullable inputs. With rich errors, this problem may become even more common and harder to predict, because there can be many different errors, not just a single null value.

Yes, this may make generic functions less ergonomic to write, but there are not that many of them compared to ordinary functions. For generic functions, correctness is therefore significantly more important than implementation ergonomics. That said, this is still a tradeoff, and we may reconsider it during the experimental phase.

[e2e4b6b7]

Note: the first signature in @kyay10’s example is not allowed, because

Only error classifier-like types are allowed on the right-hand side of the \ operator.

And type parameter is not a classifier

[rnett]

The expected behavior is not to opt in to all errors used inside the function, but only to the errors exposed in its signature, and to write generic functions in a safe way that works correctly for all possible input values.

That's not what I'm saying. My concern is that any function that takes a generic as input (e.g. input: T) is unable to use any error-returning functions that would return T | SomeError with those inputs because T may happen to contain SomeError. Writing any kind of generic method or class has to specifically exclude the errors from any functions it may want to use, and users can't alter this (e.g. to add extensions).

[rnett]

It looks like the stdlib, and possible user libraries, will now often end up with three variants of the same function: foo (throwing), fooOrNull, and fooOrError. This seems less than ideal, both from an authoring perspective and a discoverability perspective. The different variants can also be trivially derived from any single one. Have you given any thought to making this easier to work with?

[kyay10]

IMO, I think foo(returning error) should be the default variant, from which you can easily derive the orNull and orThrow variants.

[e2e4b6b7]

We see the issue, but we do not yet have a clear answer for how to address it.

We think the best default version is the error-returning one. It provides type safety and precision, and it also allows simpler conversion into other forms.

Unfortunately, derivability is not always trivial. For example, we cannot simply say that the nullable version is equivalent to fooOrError().ifError { null }. This does not work for cases such as List<T>.firstOrError(): T | Empty, because the error type itself might be a value from the list.

The proper translation would need to check for all error classes explicitly mentioned in the signature:

fun <T : Any? \ Error1 \ Error2> List<T>.fooOrError(): T | Error1 | Error2

fun <T : Any? \ Error1 \ Error2> List<T>.fooOrNull(): T? {
    val result = fooOrError()
    if (result is Error1 || result is Error2) return null // or throw for the OrThrow version
    return result
}

Note: This is possible only because of the error traceability requirement. Otherwise, Error1 could have come from the list itself.

So, it might be possible to write a compiler plugin that generates the other versions from the error-returning one.

It might sound nice to support this directly at the language level, but so far we have not found a way to make it predictable, readable, and not require the corresponding functions to be written in some specific form.

Note: the OrNull version may not be that useful in the presence of an error-returning version. Both approaches treat errors as values, but the error-returning version is safer and more precise.

[CC007]

The OrNull variant would probably only be useful for compatibility reasons and/or if you don't care about what specific error you got. In that case T.ifError{} might suffice (or |: and |! if it's decided that those are added too)

[rnett]

What is recoverable (i.e. should be an error) and what isn't (i.e. should be an exception) differs at different layers of applications. The stdlib helpers help with going from error to exception, but not the other way around, and are all or nothing. I made a similar comment on the first KEEP which I think is still relevant here. Easier ways to say "treat this particular exception as an error", "catch the KotlinErrorException for this error", and "treat this particular error as an exception" are still important and still missing.

[kyay10]

"treat this particular exception as an error",

That's just try-catch!

catch the KotlinErrorException for this error

inline fun <reified E: Error, T: Any? \ E> catchError(block: () -> T): T | E = try { block() } catch(e: KotlinErrorException) { e.error as? E ?: throw e }

treat this particular error as an exception

inline fun <reified E: Error, T: Any? \ E> (T | E).throwIfError(): T {
contract { returns() implies (this@throwIfError is T) }
if (this is E) throwError()
}

[rnett]

If it's at all possible, I think it would be very valuable to relax the "no supertypes" restriction for errors. Errors often have their own conceptual hierarchy with associated contracts, e.g. a HttpError with a url, with more specialized subtypes that each must have a url. This can be observed in libraries' use of exceptions. This is impossible to represent in the current proposal.

Even if it's somewhat restricted, e.g. interface only or not being able to use them in the error union part of the type signature, it would still be very helpful for representing actually "rich" error states.

[IRus]

You would still need a when to access that property.

Right, and when would also be required if interfaces not allowed in the union syntax.

[CLOVIS-AI]

No?

interface WithId {
    val id: String
}

error object Error1 : WithId {
    override val id: String = "ERROR_1"
}

error object Error2 : WithId {
    override val id: String = "ERROR_2"
}

fun foo(): String | Error1 | Error2 =
    TODO()

fun WithId.pretty(): String =
    "Error ${this::class} happened with ID $id"

fun main() {
    println(foo().ifError { it.pretty() })
}

• There is no when inside this sample
• It doesn't add complexity in the language (since the interface is not allowed as part of the union)
• The interface is still useful to categorize errors and reduce the amount of code

[IRus]

@CLOVIS-AI No, because this is not on the table right now. And it wouldn't work generally, with open unions it would never work.

[CLOVIS-AI]

From what I understand, 'interfaces within unions' complexifies resolution quite a lot, but I don't see the difficulty if the interface is not allowed in the union.

[fzhinkin]

I'll add my two cents: there are indeed error domains where some hierarchy (even a flat one) makes sense.

One example could be I/O operations returning a variety of errors associated with a file:

error class FileNotFound(val filePath: String)
error class InvalidEncoding(val filePath: String)
error class AccessDenied(val filePath: String, reason: String)
...

typealias IOError = FileNotFound |  InvalidEncoding | AccessDenied | EndOfFile | Interrupted | ...

// It is not always possible to handle each and every IOError at the call site and it has to be propagated upwards,
// but then good luck extracting a filePath from it.
fun File.readTextFully(): String | IOError { ... }

With HttpError, there's even more obvious shared property - its code. And depending on the context, it might be useful to covert HttpError to a corresponding code (which would require a huge when written somewhere). Conversion from a code to an error would require some mapping anyway, though. 😢

[zhelenskiy]

1. I fully agree with @rnett here that the errors can be and often are wider than their callers. If I have an internet connection error, I don't want to specify a new error type for each internet-related function for the ability to merge them. If I want to provide the information, I can put additional data in the primary constructor properties.

2. When speaking about interfaces for error types, I guess type aliases can work for now. error interfaces can be introduced IMHO with the limitation that one error class/interface can inherit not more than one interface in case of disjunctiveness being preserved. The use case for that may be having exact Internet error classes private, while having InternetError public, so consumers of the library won't depend on specific implementations but the library internals would. That would make the implementation change source-compatible.

3. We can also add helper annotations to generate throwing wrapper and or null wrapper with a piece of advice to move to the new API. It can simplify and speed up simpler migration.

4. Maybe call the type not Value but Success/Regular/Primary because value types have a different semantic?

5. Are generic error types supported as bounds?

   fun <T : Error, G : Error \ T> f(x: T, y: G): T | G =  ...

6. If the disjoint restriction is removed, I don't understand what changes in already existing code, especially if we add

   error object Null

   and make T? be equal to T | Null. Then Nothing? becomes Nothing | Null or simply Null. And the existing safe operators don't change the meaning as they previously worked for one error type Null and now they work for others the same way.

   I generally did not understand what breaks in the existing operators in any case as if some Any? is not statically a potential error type (which is not possible for the existing code), the behaviour will remain unchanged.

[kyay10]

The problem with error object Null is now that Null is Error, which can be a valid design decision, but I see why they don't want it.

if some Any? is not statically a potential error type (which is not possible for the existing code), the behaviour will remain unchanged.

The point is code reuse and compatibility. A user using rich errors might consume a library that was compiled before they were introduced (or didn't have them enabled). The intention of a library developer writing foo!! is to throw on nulls, but now that behaviour will change depending on what Kotlin compiler version you used, and it means that vast swathes of code that didn't like nulls for whatever reason now also reject errors, even when that wasn't the intention.
Another important point is generics, which is explored here in the proposal.

[IRus]

@zhelenskiy It's easier to discuss a single comment per thread

[zhelenskiy]

Ok, I'll do it this way the next time

[e2e4b6b7]

1. Answered in Rich Errors #487 (comment).

2. Answered in Rich Errors #487 (comment).

   Also, I would not say that your example represents the expected usage of errors. Internal library errors are internal and are used for implementation-internal computations. When errors are exposed to users through the API, they should not be abstracted behind an interface. The expected approach is to define a separate public set of errors for the API.

3. That is an interesting idea. We will consider this option.

4. Thanks for the options. We will discuss them later.

5. Yes, they are, but not in the way shown in your example:

   fun <E1 : Error, E2 : E1> foo() // fine
   
   fun <T : Error, G : Error \ T> f(x: T, y: G): T | G
   // Not supported: only error classifier-like types are allowed on the right-hand side
   // of the "\" operator, and a type parameter is not a classifier.

6. The issue appears when code passes rich errors to a library compiled with an older version of Kotlin. Later, when the library is updated, this may change the behavior.

[zhelenskiy]

5. Yeah, the question was whether I could require two distinct generic error types

[EdwarDDay]

In Proposal -> Design -> Types -> Illustrative examples - The 3rd example looks wrong to me. I don't understand, why E | ParseError \ OtherError should inherit from E | OtherError. It looks like a copy and paste mistake. But this would make more sense to me:

graph BT
    Neg2["E \ ParseError \ OtherError"]
    Neg1["E \ ParseError"]
    Neg1'["E \ OtherError"]
    Union["E | OtherError"]
    Union'["E | ParseError"]
    
    UnionNeg["E | OtherError \ ParseError"]
    UnionNeg'["E | ParseError \ OtherError"]
    
    Neg2 --> Neg1
    Neg2 --> Neg1'
    
    Neg1' --> E
    Neg1' --> UnionNeg'
    Neg1 --> UnionNeg
    Neg1 --> E
    
    UnionNeg' --> Union'
    UnionNeg --> Union
    E --> Union
    E --> Union'

Loading

[e2e4b6b7]

Yes, that was definitely a mistake. Thank you for catching it. Fixed.

[EdwarDDay]

Would the Java interoperability plugin also make sense for other backends? At least for Objective-C / Swift?

In Kotlin/Native, the same concerns that apply to the JVM also apply to Objective-C and Swift interop. As a result, declarations with error-union signatures are not exported to Objective-C or Swift.

So sounds to me as these would also benefit from the same plugin capabilities.

[e2e4b6b7]

Yes, this definitely might happen. Objective-C / Swift interop has similar concerns, so similar adaptation mechanisms may make sense there as well. Some parts might even become part of the default export behavior, for example, transforming top-level errors in return position into exceptions.

This area has not been finalized yet, as there is still a long way to go.

[kyay10]

I like the addition of a non-Error supertype, but why not have it simply be Any / Error? It reads nicely enough (any not error). It could even be a typealias:

typealias Value = Any / Error

I'm conflicted on the Value naming because of the confusion with value class, as you mentioned. It feels likely to me that value classes might need to add some value-class-supertype, and Value would be a great name for that.

[whyoleg]

See also #487 (comment). Would also be glad to hear why you think Value in the form of typealias is needed at all.

[kyay10]

I think ifError can be simplified quite a bit.
Firstly, T is rather useless. The compiler can already handle upcasting with lambdas just fine, so the distinction between T and R doesn't provide much. It can be removed completely.

Alternatively, I believe it can be simplified to the following:

inline fun <T : R \ Error, R, E : Error> (T | E).ifError(onError: (E) -> R): R {
    contract {
        callsInPlace(onError, InvocationKind.AT_MOST_ONCE)
        (this@ifError is Error) holdsIn onError
    }
    return if (this is Error) onError(this) else this
}

It feels much more readable to me.
If restrictions were more relaxed w.r.t. combining \ and |, we get this beautiful signature:

inline fun <R, E : Error> ((R \ Error) | E).ifError(onError: (E) -> R): R {
    contract {
        callsInPlace(onError, InvocationKind.AT_MOST_ONCE)
        (this@ifError is Error) holdsIn onError
    }
    return if (this is Error) onError(this) else this
}

I think 2 type parameters is very likely the minimum here, so this is optimal!

[CC007]

Wouldn't this just work?

inline fun <T: Value?, E: Error, R: T | Error> (T | E).ifError(onError: (E) -> R): R {
    contract {
        callsInPlace(onError, InvocationKind.AT_MOST_ONCE)
        (this@ifError is Error) holdsIn onError
    }
    return if (this is Error) onError(this) else this
}

I feel it's easier to reason from the parameter forward, rather than from the result type backwards. I get that it might be needed for Kotlin's internals and it being a nice-to-have for people that DO want to reason backwards, but why complicate things when it's not needed to do so?

[kyay10]

There's something to be said about the splitting of parameters like T|E. If you allow intersections with just Error, it can get a lot simpler. We can then just use a single generic T, and extract the value component using T \ Error, and the error component using T & Error. There's precedent with the T & Any syntax for removing nullability.

[kyay10]

Just as there's a returnsNotNull contract, I think a returnsValue and returnsError contracts might be helpful.

[mikehearn]

I'd like to echo @nikclayton's feedback and also sharpen it a little. KEEPs exist to collect user feedback and review. They have no other purpose, as most Kotlin design work was successfully done without them for many years.

When you repeatedly ask long term users for feedback and then ignore it, it's demotivating. I've been using Kotlin since before it even had a website, long before the 1.0 release, and first questioned the recoverable/non-recoverable distinction on YouTrack nearly a year ago. That same concern has been echoed by many other developers since. But it has never been addressed, perhaps because design work was already done and this argument calls into question the value of that work.

Yet a strength of Kotlin has always been what it did not include, not only what it did. As Kotlin has become ever more mature it's inevitable that more KEEPs will receive feedback that questions the premises of a proposal, simply because the low hanging obvious fruit everyone can agree on is ever more picked.

A symptom of this is that the KEEP makes some very subjective claims, like:

This leads to fragmentation across APIs and inconsistent ergonomics.

I've used many Kotlin libraries and never encountered custom error types, so I've not personally seen or suffered from any fragmentation or inconsistent ergonomics. I have however suffered from being required to debug Go codebases where error types meant there were no useful stack traces. It would be good to be convinced my experience is atypical with data, but none is forthcoming.

There are so many excellent additions that could be made to Kotlin and so few that can ultimately be added. Is a feature with a questionable core premise really the best place to spend your limited budget?

[zarechenskiy]

It would be good to be convinced my experience is atypical with data, but none is forthcoming.

I tried to include some of such data in the motivation section around other languages and ecosystems. The trend is that most mainstream and newer emerging languages adopt “errors as values” model in one form or another: with Result<T, E>, (result, err) or similar. We also see increasing use of explicit Result-style APIs in Kotlin today.

A symptom of this is that the KEEP makes some very subjective claims, like:

This leads to fragmentation across APIs and inconsistent ergonomics.

I also tried to reflect this in the first doc with examples from the IntelliJ IDEA repo, third-party libraries that introduce Either or Result and just code that uses our own Result type. In general, what you find online about error handling in Kotlin is that it's not consistent.

Especially given that our own Result was originally designed for quite specific cases, but is now used for general error handling (it's in some of our API and can server as a hint to use it as well), but also one of the reasons other libraries implement their own Result or Either classes.

When you repeatedly ask long term users for feedback and then ignore it, it's demotivating

I'm sorry if it comes across that way. I admit that I could be more responsive to comments. However, we are definitely collecting user feedback, and for concerns where we still believe our arguments stand, we don’t think cancelling the feature is the right approach. Instead, we’re not rushing with the feature, gathering more data and potential problems. In general, if we were 100% sure about a feature from the start, there would be no need to create KEEPs at all.

--

What I also feel is that rich errors might be perceived as replacing exceptions. That’s not our goal at all. Our goal is to streamline the usage of Result-like APIs and leverage Kotlin’s strengths such as smart casts. Maybe the proposal is missing clear guidelines on which error-handling approach to use in different situations, but then let’s discuss that.

[nikclayton]

@zarechenskiy

Maybe the proposal is missing clear guidelines on which error-handling approach to use in different situations, but then let’s discuss that.

Please could you instead search this discussion for the phrase "Please properly address these concerns" and then properly address the concerns raised in the text that precedes it.

I am struggling to see how I could have made that request any clearer.

Thank you.

[IRus]

Did you consider open unions to be default or default in the library mode?

[Laxystem]

To me, the | in foo()|.bar() reads like an OR operator, and my brain assumes XOR behaviour: "do foo, else, do bar".

Perhaps a different operator would be preferred? I've thought of ->, which even already inherits some distant memory of "unboxing"-ation from C++.

E.g.

fun fetch(): User | NoSuchUser
fun User.charge(): Transaction | TransactionCancelled

fun foo() {
    val transactionResult = fetch()->charge()
    if (transactionResult is Error) {
        when (transactionResult) {
            is NoSuchUser -> println("User not found")
            is TransactionCancelled -> println("Transaction cancelled")
        }
    }
}

But unfortunantly, Kotlin already uses -> in lambda types and when, which makes it look kind of funky. Perhaps \.? This bears resemblence to the "NOT error" syntax Obj \ SomeError; Mental model-wise, The type of a "something\" would be \ Error'd when being dot-accessed.
One can also derive \: (meaning "[in case of] no value, do:") quite easily.

fun fetch(): User | NoSuchUser
fun User.charge(): Transaction | TransactionCancelled

fun foo() {
    val transactionResult = fetch()\.charge()
    if (transactionResult is Error) {
        when (transactionResult) {
            is NoSuchUser -> println("User not found")
            is TransactionCancelled -> println("Transaction cancelled")
        }
    }
}

[Sporking]

It seems to me that the "a|.b|.c()" syntax is confusing from a boolean analogy point of view. If it were written as "a&.b&.c" I could make an analogy between "a function returns a value (and not an error)" and "true (and not false)". Thus the whole expression returns a value if a returns a value AND b returns a value AND c returns a value, and otherwise it returns an error. However, "|." leaves me scratching my head: what does "a|.b" actually mean, by analogy with booleans? I would expect this to return the value type returned by a OR b, which makes little sense.

I think that errors should conceptually be associated with falseness and non-errors should conceptually be associated with truth, so I think using an "&." operator rather than an "|." operator more closely expresses that.

Incidentally, "pipe" operators in some language use a "|>" token which works somewhat similarly to your "|." operator. It is also worth considering:

    val x = foo()
            |> bar()
            |> baz()
            .onError { return it }

[IRus]

For Kotlin |> doesn't work, since it's missing . which is telling that right side receiving what computed on the left. For me Unix shell analogy to Pipe operator makes total sense when looking at proposed syntax:

val x = foo()
    |.bar()
    |.baz()
    .onError { return it }

[Sporking]

@IRus But in this case the right side ISN'T actually receiving what is computed on the left. It's receiving only a subset of what was computed on the left, namely the non-error value part of it, while passing the error part of it on through via a parallel channel. UNIX pipes don't work that way. Also, the calls on the right of a "|." aren't guaranteed to occur, as they would be in a UNIX pipe: Instead, they're conditional, and only happen if the thing to the left of them didn't calculate to an error. In general, it seems to me that using a UNIX pipe as an analogy here is misleading and likely to be confusing, because this structure doesn't really act like a UNIX pipe. It does act somewhat like "?.", but that's not really like a UNIX pipe either.

[MJavoso]

Rich Errors currently model alternative failures (A | B | C). Has support for accumulating failures been considered? Validation is a common example where multiple errors are expected simultaneously rather than failing fast. I've read the KEEP, but in the examples provided, a function can return either: an object representing success or any of the errors, but only one of them. Take this for example:

error object EmptyName
error object InvalidEmail
error object PasswordTooShort
typealias UserErrors = EmptyName | InvalidEmail | PasswortTooShort

fun validateUser(user: User): Unit | Errors<UserErrors> { //Special collection only for errors
    val errors = mutableErrorListOf<UserErrors>()
    if (user.name == "") errors.add(EmtpyName)
    if (!user.email.contains("@")) errors.add(InvalidEmail)
    if (user.password.length < 8) errors.add(PasswordTooShort)
    
    if (errors.isNotEmpty) return errors
}

fun login(user: User): Token | Errors<UserErrors> {
    validateUser(user).ifError { return it }
    
    return getLoginToken(user) // Potentially with more UserErrors
}

While this can already be modeled by introducing another error type that wraps a collection of errors, like this: error class UserErrors(val errors: List<UserErrorsKind>), it feels like unnecessary boilerplate for such a common use case. Has the idea of a dedicated aggregation type (for example Errors) been considered? That would preserve the error type while allowing APIs to return multiple failures without introducing an additional wrapper hierarchy.

[e2e4b6b7]

Thank you for sharing this use case.

The main obstacle to supporting an abstraction like Errors<E> is the use of generics. Generic error types are possible in principle, although they would likely require additional restrictions. However, for the initial version of Rich Errors, we would like to focus on the core part of the feature and consider extensions such as generic error types and inheritance later.

For now, the best available option is the one you described: introduce a dedicated error declaration that wraps the collected errors.

[Sporking]

I think that using the term Error for these features is likely to cause problems. On the JVM, the term Error already has a clearly defined history and meaning: it refers to java.lang.Error, an exception supertype that is thrown to indicate serious conditions and generally should not be caught (VirtualMachineError, AssertionError, etc.). Having a new set of features also use the term Error very widely for something completely different is quite likely to create confusion. Particularly since the new features tend to cause people to create lots of new classes with names ending in "Error", just as the standard Java coding practices for using java.lang.Error do. Name collisions are going to happen.

I suggest using Err instead. It avoids collision with java.lang.Error also has the advantage of being shorter. So foo.onErr { blah } and so forth. Since this feature is expected to be used quite frequently, in the midst of code that may already be complicated for other reasons, I think that conciseness (and conservation of horizontal space) should be treated as rather important.

[lsafer-meemer]

What about "Fault"?

[Sporking]

I'm not in love with "Fault" but it's better than "Error" because at least it doesn't cause name collisions. I still think "Err" is better due to its conciseness. "Fail" might be another alternative worth considering.

[CLOVIS-AI]

I've used Failure before.

[e2e4b6b7]

We have updated the document after discussions preceding implementation of experimental version:

• Negative types were removed to simplify the model and improve readability
• Error traceability restriction transformed from typing error into just a warning for the same two places (|. and generic function call)
• Value class turned into an interface (minor technical adjustment)

[zarechenskiy]

Since the design has changed quite a lot, we've also published a document with our analysis of how Rich Errors could be used today in a few projects (DuckDuckGo-Android, Anki-Android, and Signal-Android): Evaluating Rich Errors in the Wild.

Feel free to check out the document and share your thoughts or more use cases in the discussion #498

[igotfr]

why not use ! to separate the Ok from Errors and | to separate the Errors?

error class SaveNoteFailure(val message: String? = null)
error class SaveNoteWarning(val message: String?)

suspend fun saveNote(): Unit ! (SaveNoteFailure | SaveNoteWarning)

[igotfr]

@CC007 I don't want 2 different kinds of classes, I did to fit the proposal, argue with the other guys about it

the reason why Scala 3, for example, has both, Either and union types, it's to call methods (map, flatMap, fold, etc) on Either values and special operators:

• Scala has a specific try-catch to handle Either and for comprehension is used to propagate (although I find it strange)
• Rust has ? to propagate, since there is no special operator to error handling and match is used, error handling in Rust is verbose, you have to do things like Ok() and Err() in each arm multiple times
• Swift has try to propagate and do-catch to error handling

[igotfr]

@CC007 I personally would propagation and error handling:

val res: Value ! Error = f();

// to propagate
val v = res.try

// error handling
handle res {
  patternValue1 => do_something,
  patternValue2 => do_something,
} catch {
  patternError1 => do_something,
  patternError2 => do_something
}

[corlaez]

well the problem I see here is dual @igotfr @CC007

1. I understand they are actively don't want to do union types due to performance. Dont's
   • Having regular classes as error
   • Having more than 1 success result
2. Having more than 1 success result also forces you to use when or when-like constructs because you can't know which functions the result will have.
3. The error handling block... is basically a when expression, with an artificial separation. I really hard to see how this is any better than when , and therefore why it makes sense to only return one main type

[CC007]

For 1, why is having regular classes as return type a performance issue? You could just as well have created an error class wrapper for that regular class, so I don't see why the compiler can't do that ad-hoc for the developer as syntactic sugar?
Also, why does having more than 1 success result cause performance issues, if that's basically what would happen if you use a sealed class as your success result type?

I mostly agree with 2. If you really need multiple return types, you can always use a sealed interface or abstract class yourself... unless the two return options are part of a library, so you can't make them implement the interface?

I fully agree with 3.

[igotfr]

@corlaez

1. if the problem with union type is performance, ok, I understand
2. yes, is how it works in Scala, but with map, for example, the match cases only the Right union types

case class InvalidInput(message: String)
case class FileNotFound(path: String)

def loadConfig(
    path: String
): Either[InvalidInput | FileNotFound, String | Int] =
  if path.isEmpty then
    Left(InvalidInput("caminho vazio"))
  else if path == "config.json" then
    Right("""{"port": 8080}""")
  else if path == "a.txt" then
    Right(4)
  else
    Left(FileNotFound(path))

val r = loadConfig(s"a.txt")
println(r.map(_ match
  case s: String => s"String: $s"
  case i: Int => i * 2
))
// output: Right(8)

3. the error handling block serves to automatically unwrap the Ok and Err in languages with Result type, in Kotlin with error union, it would a syntatic separation between values and errors

[CC007]

To follow @Sporking in why the name Error might not be the best, I could see this being useful for more than just dealing with errors.

From the design I've seen, it's more like modeling an alternative flow and the concatenation thereof in monadic types, without having to define a wrapper type for every combination of main flow and (multiple) alternative flow types. Errors aren't the only thing where you'd want to model alternative flows, so calling them error types that are an instance of Error only adds to the confusion once they are inevitably going to be used for other alternative flow scenarios too. We'd have java's problem of defining singletons as enums all over again.

[corlaez]

uhm... like Alt? Alternative?

I mean I see what you are saying, in the end this is a non main return that provides some metadata. Error is the canonical example. but could you provide more concrete examples of how error can be used that doesn't correspond to the concept of error?

[CC007]

I like the alt keyword!

Also, if the term error is dropped, then calling the feature Rich Errors is a bit of a misnomer. I'd say it would be closer to saying they're Ad-hoc Chainable Monads.

• Monads, because there's a clear distinction between the main flow and alternative flows.
• Ad-hoc, because you don't have to write a wrapper class for the monad (so no need to create a Result or Optional type).
• Chainable, because the |. operator allows you to chain monad mapping functions together.

As for when an alt type isn't necessarily an error type: one I could think of was an intermediary identity provider (IdP), who may or may not need to first redirect to the downstream IdP when trying to log out, depending on what's recorded in the session data.

data class Data(messageId: UUID, issuer: URI, signature: Signature, token: Token)
data class Session(sessionId: UUID, expires: DateTime, idpLogoutUrl: URI?)

alt object SignatureInvalid
alt object ContentMismatch
fun Data.validate(): Data | SignatureInvalid | ContentMismatch {
    // validate if the signature used the right certificate and whether the request contents are properly signed
    ...
}

alt object SessionNotFound
fun Data.withSession(): Pair<Data, Session> | SessionNotFound {
    // look up session based on the logout request token
    return this to SessionStore.forToken(this.token)
}

// this one is not an error, but it does short-circuit the logout, since no session should be deleted yet until the user is redirected to the IdP logout and then returned back to the /resume-logout endpoint
alt class IdpLogoutRedirect(redirectURL: URI) 
fun Pair<Data, Session>.handleIdpRedirect(): Pair<Data, Session> | IdpLogoutRedirect =
    // return the alt class when the idpLogoutUrl is set
    this.right.idpLogoutUrl
      ?.let{ return@handleIdpRedirect IdpLogoutRedirect(it) }
      ?: return this

alt object SessionDeletionError
fun Pair<Data, Session>.deleteSession(): Data | SessionDeletionError {
    // this only gets called on sessions that don't first have to be redirected to the downstream IdP provider
    SessionStore.delete(this.right.sessionId)
    return this.left
}

data class Success(messageId: UUID, responseId: UUID)
fun Data.buildResponse(): Success {
    return Success(this.messageId: String, UUID.random())
}    

typealias Error = SignatureInvalid | ContentMismatch | SessionNotFound | SessionDeletionError 

fun logout(data: Data): Success | IdpLogoutRedirect | Error = data
        .validate()
        |.withSession()
        |.handleIdpRedirect()
        |.deleteSession()
        |.buildResponse()
}

It is clear that a lot of the alt objects are indeed errors, but not all of them. IdpLogoutRedirect is not an error. It is a valid part of the flow, but doesn't need to go through the whole session deletion and response building part until it comes back on the /resume-logout endpoint, after having been redirected to the IdP.

[CC007]

Also, as I see it, this new notation is basically a generalization of nullable types.
With Rich Errors, Int? could have just as easily been implemented as Int | Null, where Null is defined as alt object Null. In that case |. would basically act the same as ?..

This is also why I think it would be useful if |: was added as a counterpart to ?:, meaning orElse(...) and |!as counterpart to !! (or !! could be made to work with rich errors), meaning orThrow().

Not all null values are errors. It just denotes the absence of a value. Ironically, if you have a function like

fun <V: Value, E: Error> (V|E).getError(): E | Null = ...

(aka E?), the Null is actually the OPPOSITE of an error. It's the absence of an error.

PS: with alt:

fun <V: Value, A: Alternative> (V|A).getAlternative(): A | Null = ...

[corlaez]

Wow, yeah I see what you are saying with Null as an error/alt. No idea if Kotlin would ever go that way but technically it could if error/alt is added and powerful enough.

Ok. I see, so essentially your error/alt is pretty much like a sealed interface (i mean you can achieve that today with sealed interface, success and error paths) but in a union type flavor.

Alt sounds really good to me, no idea if there is appetite for that but it also solves the fact that error is already a JVM concept.

I need to read more about the keep, i only saw a video, but it is pretty old and probably outdated.

[CC007]

While I do understand that the first argument in : ResultType | AltResultType1 | AltResultType2 is special in that you can use the |. operator to chain with that first type, I don't fully understand why the types after that need to be a special kind of type (for now an error type, but see my previous comment on why I dislike the name). What specific restrictions does an alternative flow type need to have to function and why are those restrictions necessary? Is there an alternative way to enforce those restrictions? Why can't normal types be used when they meet those restriction criteria?

[fzhinkin]

Since errors can't implement interfaces, are they expected to be always non-serializable on JVM (not implementing java.io.Serializable) or the interface will be implemented implicitly?

[corlaez]

perhaps that can be a compiler plugin.

errors should hopefully allow being annotated with kotlinx.serialization.Serializable

[CC007]

Has anyone considered treating Value? as Value | Null where the questionmark is just syntactic sugar?

This would also allow for remaining backwards compatible with the current hierarchy from before rich errors, without needing to introduce the Value type (or it's introduced as typealias Value = Any). We'd just need to have a new name for the root, like Object (Or Root. Feel free to suggest a better name) or it could just be kept explicitly separate as Any | Error

graph BT
    NothingError["Nothing | Error"]
    IntError["Int | Error"]
    Object["Object (Any | Error)"]
    NothingNParse["Nothing? | ParseError \n(Nothing | Null | ParseError)"]
    AnyNParse["Any? | ParseError \n(Any | Null | ParseError)"]
    IntNParse["Int? | ParseError \n(Int | Null | ParseError)"]
    NothingParse["ParseError \n(Nothing | ParseError)"]
    IntParse["Int | ParseError"]
    AnyParse["Any | ParseError"]
    NothingN["Nothing? (Nothing | Null)"]
    IntN["Int? (Int | Null)"]
    AnyN["Any? (Any | Null)"]
    Nothing["Nothing"]
    Int["Int"]
    Any["Any"]

    Nothing --> NothingParse
    Int --> IntParse
    Any --> AnyParse

    NothingN --> NothingNParse
    IntN --> IntNParse
    AnyN --> AnyNParse

    subgraph BRE [Before rich errors]
        subgraph Value
        Nothing ---> Int
        Int ---> Any
        end

        subgraph Nullable value
        NothingN ---> IntN
        IntN ---> AnyN
        end

        Nothing --> NothingN
        Int --> IntN
        Any --> AnyN
    end
    style BRE fill:#555

    subgraph WRE [With rich errors]

        NothingParse --> NothingNParse
        IntParse --> IntNParse
        AnyParse --> AnyNParse

        NothingNParse --> NothingError
        IntNParse --> IntError
        AnyNParse --> Object

        subgraph Value or Error
        NothingError ---> IntError
        IntError --> Object
        end

        subgraph Value or ParseError
        NothingParse ---> IntParse
        IntParse ---> AnyParse
        end

        subgraph Nullable value or ParseError
        NothingNParse ---> IntNParse
        IntNParse ---> AnyNParse
        end
    end
    style WRE fill:#555

Loading

That way:

• ?: would be equivalent to:

  fun <A: Any, E1: Error, E2: Error> (A|E1).ifNull(default: A|E2): A|E1|E2 {
      // I don't know how to define this function so that the compiler knows
      // that if A|E1 isn't Null, the return value isn't Null either. Maybe contracts could help here?
      if(this is Null) return default // or if(this == null) return default
      return this
  }

• someVal!! would be equivalent to:

  fun <A: Any, E: Error> (A|E).ifError(onError: (E) -> Nothing): A {
      contract {
          returns() implies (this@ifError is Any)
          callsInPlace(onError, InvocationKind.AT_MOST_ONCE)
          (this@ifError is Error) holdsIn onError
      }
      return if(this is Error) throw onError(this) else this
  }
  
  fun <A : Any, E : Error> (A|E).throwIfError(): A {
      contract {
          returns() implies (this is Any)
      }
      return ifError { it.throwError() }
  }
  
  someVal.throwIfError()

• ?! could be introduced. someVal?! would be equivalent to:

  fun <T: Any|Error> T.throwIfNull(): T {
      contract {
          returns() implies (this !is Null)
      }
      return if(this is Null) throwError() else this
  }
  someVal.throwIfNull()

• ?. would just be an alias for |. (or would it just act on Null values, just like the ?! that I mentioned? The difference matters for cases like Int?|ParseError)

[CC007]

"But @CC007," you might ask, "What about generic implicit bounds like <T>? Wouldn't it be an issue for existing code to suddenly have this bound become <T: Any | Error>?"

Yes! That's why I argue to make bounds that include errors other than Null opt-in and keep Any?, aka Any | Null as the default bound. That means that if you want to support Error types in your generics, you'd have to be explicit about it, for instance <T: Any? | ParseError> or <T: Any | Error>

[corlaez]

that sounds pretty cool to me, and honestly would make sense to just use ?. and !! at that point.

If Foo?is just syntactic sugar over Foo | nullwhere null is treated asalt object nullbut is special since it isnull` then it makes a lot of sense to reuse ?. and !!. Only that null has a special exception associated to it.

Only elvis operator is a bit tricky, but perhaps could be overloaded to take a lambda:

x() ?: { altValue -> ... }

In any case, I actually like it a lot. but it would have to reimagine how our whole understanding of type hierarchies in Kotlin work. So in someway this is sounding like a much wider scope, like a Kotlin 3.0 matter, so I would avoid discussing here. Also notably would require first that we get some form of error/alt implementation first, before we can reimagine how nullability is modeled and handled.

At least I think it is a separate discussion.

[CC007]

The only reason I see for the questionmark and pipe operators to remain separate is as a shorthand to quickly deal with null cases, without having to deal with other alt/error cases. Dealing with null will probably remain important, so I don't mind if it gets special treatment (aka. extra syntactic sugar).

Assume you have val myDto: Dto | Null | ParseError (aka Dto? | ParseError) and the following functions:

fun Dto.toData(): Data | MappingError = TODO()
fun (Data | ParseError | MappingError).handleErrors(): Data = TODO()

Here both the |. and ?. are useful:

val myData: Data = myDto
    |.toData() // bypass all alt/error types including Null
    ?.handleErrors() // bypass only Null values
    |: { _-> Data.default } // Null is the only alt/error type remaining, so `?: Data.default` also works.

Or if you want to get a default dto value, ?: only handling Null is still useful:

val myData: Data = myDto
    ?: Dto.default // since we only deal with Null here, the type is Dto | ParseError
    |.toData() // bypass ParseError. The type will be Data | ParseError | MappingError 
    .handleErrors() // no need to bypass Null anymore, since that's already dealt with

Without the distinction, we'd need to do this:

val myData: Data = myDto
    |.toData()
    .let {
        when(it) {
            is Null -> it // or `is Nothing?`
            else -> handleErrors()
        }
    }
    ?: Data.default()

Or with Dto.default, the without |: as is the current proposal:

val myData: Data = myDto
    .ifError {
        when(it) {
            is Null -> Dto.default
            is ParseError -> it
        }
    }
    |.toData()
    .handleErrors()

I do like the lambda if it were for |: though:

x() |: {altValue -> ...}

It's slightly more concise than x().ifError {altValue -> ...} and mirrors ?: nicely. It also looks better in a method chain:

With lambda data |.doSomething() |.someProp |: { fallback(it) }

With method reference data |.doSomething() |.someProp |: ErrorHandler::fallback

Null-safety counterpart data ?.doSomething() ?.someProp ?: fallback()

[corlaez]

Can we have our cake and eat it too?

Proposal: If we are to have a whole set of special objects that can be somewhat have union operations, why don't we zoom out a bit of error and implement "sensible" union in kotlin.

1. alt instead of error. More flexible, generic intent.

2. If you use a regular class as first value and a bunch of alts after, compiler can assume regular class as the main type and make assumptions. Alt's are alternative paths that must be dealt with separately. This can work with ?. and !! or whatever equivalent we want if we want to keep them separate from those (elvis could work as well if right side is a lambda consuming the valueObject)

3. Kotlin compiler allows you to combine just alts. In this case there is no assumption that the first is main, it is treated as a union, and the caller must disambiguate, no main path or type. Also no ?. and no !! and no elvis or whatever alternative operators similar to these are defined.

This is what I mean to have your cake and eat it too:

1. Main class + alts -> Perfect for modeling error, or more generally Main path, alternative paths (some success some error)
2. alt + alts -> True union (with restrictions) without being crazy expensive or slow.

Kotlin not only gains new error handling (and alt path handling) but also gains generic unions (with limitations of course but they are there).

I think calling them error is what is pushing us to a corner with no union. If you call it alt, suddenly it is more flexible and mixing just alt's makes sense too.

[corlaez]

e2e4b6b7 can we currently combine error+error without a main class in the beggining?

could we/have we considered error not being error but just "alt"? (so it can model alternative successses and failures similar to sealed classes)

[CC007]

To my knowledge E1 | E2 is allowed, since this is basically just Nothing | E1 | E2. E1 and E2 just have to be mutually exclusive for the Error tracability restriction.

Regarding alt. I looked at the wiki page for monads (since this proposal is basically just ad-hoc monads). It calls them variants. I think I'd be okay with either variant class Foo(...) / variant object Bar or alt class Foo(...) / alt object Bar. Both are in my opinion more descriptive than error class Foo(...) / error object Bar

[CC007]

I was wondering... How would you compose two types together? I mean this regardless of whether Type? is defined as Type|Null (like I proposed before) or not.

For specific cases like Int? | ParseError and Int | MappingError, it is quite clear: Int? | ParseError | MappingError no problems there.

But what about something more general?

In a previous comment I tried to define an ifNull(...) method for when Rich Errors are introduced, but I ran into an issue when trying to define the types:

fun <A: Any?, E1: Error, E2: Error> (A|E1).ifNull(default: A|E2): A|E1|E2 {
   return if(this == null) default else this
}

This has a couple of problems:

• There could be an overlap in E1 and E2, so I don't think that the return type as I defined it there is allowed.
• I don't know how to define this function so that the compiler knows that if A|E1 isn't null, the return value isn't null either.

If we had the \ notation, I could do something like:

fun <A: Any?, E1: Error, E2: Error \ E1> (A|E1).ifNull(default: A|E2): A|E1|E2 {
   return if(this == null) default else this
}

This would at least solve the first problem. I get that adding the \ notation would add a lot of complexity that in most cases wouldn't be needed. If you have typealias E = E1 | E2 | E3 | E4, you don't need E \ E4, because you could have just defined it as E1 | E2 | E3, since you know all the types that extend E. This is not the case for Error however. There's an undetermined amount of error classes that extend from Error, so it's not possible through other means to define or reframe "All errors except that one" without the \ notation, for example Error \ ParseError.

That's why I suggest that the \ notation is brought back, but ONLY for the specific case where

• the left side of the \ is Error or derived from Error \ E (where E is any specific error type or union thereof) and
• the right side of the \ does NOT contain Error or a derivative.

Given:

error object ParseError
error object MappingError
error object ConnectionError
typealias HandlerError = ParseError | MappingError | ConnectionError

Allowed:

typealias NoParseError = Error \ ParseError
typealias NoParseOrMappingError = NoParseError \ MappingError
typealias NoHandlerError = Error \ HandlerError

Not allowed:

typealias DataError = HandlerError \ ConnectionError          // use ParseError | MappingError instead
typealias DataError = Error \ NoParseOrMappingError           // no double negatives allowed. Again, use ParseError | MappingError instead
typealias MappingAlias = NoParseError \ NoParseOrMappingError // again, don't use double negatives. This is just MappingError

Another situation where this would be in case Type? was indeed defined as Type | Null. In that case you might want to define a method that works on a monad type with any error type, except null, like for example: Int | Error \ Null

[CC007]

Here's a diagram of what the type hierarchy looks like:

flowchart BT
    Nothing["Nothing"] ==> E1["E1"] & E2["E2"]
    E1 ==> E1E2["E1 | E2"]
    E1 -..-> ErrorNotE2["Error \ E2"]
    E2 ==> E1E2
    E2 -..-> ErrorNotE1["Error \ E1"]
    ErrorNotE1E2 ==> ErrorNotE2 & ErrorNotE1
    Nothing -..-> ErrorNotE1E2["Error \ E1 \ E2"]
    E1E2 -..-> Error["Error"]
    ErrorNotE2 ==> Error
    ErrorNotE1 ==> Error

Loading

Dotted arrows are where you go from the individually enumerable error types to the realm of non-enumerable error types. This means there are an equally non-enumerable amount of union types between the enumerable and non-enumerable types, based on what other error types exist.

[CC007]

For a more concrete example, consider Int division:

error object DivideByZero

fun Int.safeDiv(divisor: Int): Int | DivideByZero {
     if (divisor == 0) return DivideByZero
     return this / divisor
}

The method calls and hierarchy would look like this:

val anInt: Int = TODO()
val maybeAnInt: Int? = TODO()
val anIntOrError: Int | Error \ DivideByZero = TODO()
val maybeAnIntOrError: Int? | Error \ DivideByZero = TODO()

val d: Int = TODO()

val divided: Int | DivideByZero = anInt.safeDiv(d)
val maybeDivided: Int? | DivideByZero = maybeAnInt?.safeDiv(d)
val dividedOrError: Int | Error = anIntOrError|.safeDiv(d)
val maybeDividedOrError: Int? | Error = maybeAnIntOrError?.let{ it|.safeDiv(d) }

flowchart BT
    Nothing["Int"] ==> Null["Int?"]
    Nothing ==anInt.safeDiv(d)==> DivideByZero["Int | DivideByZero"]
    Null ==maybeAnInt.safeDiv(d)==> NullDivideByZero["Int? | DivideByZero"]
    Null -..-> ErrorNotDivideByZero["Int? | Error \ DivideByZero"]
    DivideByZero ==> NullDivideByZero
    DivideByZero -..-> ErrorNotNull["Int | Error"]
    ErrorNotNullDivideByZero ==> ErrorNotDivideByZero
    ErrorNotNullDivideByZero ==anIntOrError.safeDiv(d)==> ErrorNotNull
    Nothing -..-> ErrorNotNullDivideByZero["Int | Error \ DivideByZero"]
    NullDivideByZero -..-> Error["Int? | Error"]
    ErrorNotDivideByZero ==maybeAnIntOrError.safeDiv(d)==> Error
    ErrorNotNull ==> Error

Loading

Or with error object Null and Int? = Int | Null:

val anInt: Int = TODO()
val maybeAnInt: Int | Null = TODO()
val anIntOrError: Int | Error \ Null \ DivideByZero = TODO()
val maybeAnIntOrError: Int | Error \ DivideByZero = TODO()

val d: Int = TODO()

val divided: Int | DivideByZero = anInt.safeDiv(d)
val maybeDivided: Int | Null | DivideByZero = maybeAnInt|.safeDiv(d)
val dividedOrError: Int | Error \ Null = anIntOrError|.safeDiv(d)
val maybeDividedOrError: Int | Error = maybeAnIntOrError|.safeDiv(d)

flowchart BT
    Nothing["Int"] ==> Null["Int | Null"]
    Nothing ==anInt.safeDiv(d)==> DivideByZero["Int | DivideByZero"]
    Null ==maybeAnInt.safeDiv(d)==> NullDivideByZero["Int | Null | DivideByZero"]
    Null -..-> ErrorNotDivideByZero["Int | Error \ DivideByZero"]
    DivideByZero ==> NullDivideByZero
    DivideByZero -..-> ErrorNotNull["Int | Error \ Null"]
    ErrorNotNullDivideByZero ==> ErrorNotDivideByZero 
    ErrorNotNullDivideByZero ==anIntOrError.safeDiv(d)==> ErrorNotNull
    Nothing -..-> ErrorNotNullDivideByZero["Int | Error \ Null \ DivideByZero"]
    NullDivideByZero -..-> Error["Int | Error"]
    ErrorNotDivideByZero ==maybeAnIntOrError.safeDiv(d)==> Error
    ErrorNotNull ==> Error

Loading

[corlaez]

Oh thanks for the explanation. I think we may be fine without the negative operation. I've got to agree that it does simplify the model.

Also negatives could always be added later if we do think we really need them.

[CC007]

Then how do you propose ifNull is implemented?
My attempt was:

fun <A: Any?, E1: Error, E2: Error \ E1> (A|E1).ifNull(default: A|E2): A|E1|E2 {
   return if(this == null) default else this
}

Since

fun <A: Any?, E1: Error, E2: Error> (A|E1).ifNull(default: A|E2): A|E1|E2 {
   return if(this == null) default else this
}

Has the issue of E1 and E2 possibly overlapping, which breaks the Error traceability restriction.

You could just do this:

fun <A: Any?> (A|Error).ifNull(default: A|Error): A|Error {
   return if(this == null) default else this
}

But then you lose information about which errors were possible, which unnecessarily results in the output becoming an open union with no information about what errors are actually possible.

The only other alternatve without \ I see for now is suppressing the warning:

@SuppressWarning("ErrorTracability")
fun <A: Any?, E1: Error, E2: Error> (A|E1).ifNull(default: A|E2): A|E1|E2 {
   return if(this == null) default else this
}

But that also feels more like a workaround, rather than a solution.

[CC007]

That's why I suggest that the \ notation is brought back, but ONLY for the specific case where

• the left side of the \ is Error or derived from Error \ E (where E is any specific error type or union thereof) and
• the right side of the \ does NOT contain Error or a derivative.

Hmm, while I stand by that first rule and I think that normally that second rule might also need to at least throw a warning if it can be simplified, the second rule might be a problem with generics. In fact, it poses a problem with the exact ifNull example I gave:

fun <A: Any?, E1: Error, E2: Error \ E1> (A|E1).ifNull(default: A|E2): A|E1|E2 {
   return if(this == null) default else this
}

Here E1 can also be any error, but you don't know what the exact overlap is between E1 and E2, since they're generic, so you can't simplify E2: Error \ E1.

Therefore I think I'd revise the uses of \ to:

• the left side of the \ MUST be Error or derived from Error \ E, where E is any specific error type or union thereof (giving a compilation error if this rule is broken) AND
• the right side of the \ SHOULD NOT contain Error nor a derivative, UNLESS it is derived from a generic negative type (giving a warning if this rule is broken)

[fxshlein]

Maybe I missed it, but would something like this be supported under the proposal?

fun List<V>.add(value: V): Unit | OutOfBounds

I guess since Unit is an object there is technically nothing stopping you from just assigning this to a variable and running an is Error and when over it, and I think its a perfectly valid use case. I'm a bit worried that this wouldn't be allowed, since there is no mention of it in the proposal, and Unit does have some special handling in kotlin.

To be useful, this would require that the @MustUseReturnValues feature also flags a union containing Unit.

[kyay10]

Unit is not that special. It's just like any other object. The only special handling for it is that it can be returned implicitly by a lambda (maybe there's a couple more exceptions)

This use case would work nicely with the return value checker to force the caller to check that it didn't error.

[kyay10]

Browsing the Kotlin spec, I see the following "special cases" of Unit:

• it's a built in type, alongside others like Nothing and Boolean
• a function block body implicitly has Unit return type
• setters must have Unit return type
• a code block or control structure whose last statement is not an expression (e.g. an assignment, a loop, etc) is considered to have Unit as its type
• a control structure body can be "coerced" to Unit if the expected type is known to be Unit.
• a non-exhaustice when or if is not an expression and has type Unit
• a return with no value implicitly returns Unit

[fxshlein]

I think its also somewhat special in this specific case because it normally compiles to javas void, but would now have to actually compile to Object and return either null or, more probably, the actual Unit object.

Not a hard or unsolvable problem in any way I think, but I was worried that there would be some argument that error unions only make sense when there is a return type, and that they would be limited in this case for philosophical reasons.

[CC007]

The return type could still be void if the errors are thrown as checked exceptions. Only when returned as an ADT, it would be an issue.