[SE-0413: Typed throws] needs union types

[frogcjn]

It is hard to use if it allow throw only one type Error.

throws(ErrorTypeA | ErrorTypeB) should be allowed

Most of the cases are throwing multiple type Error.

[xwu (Xiaodi Wu)]

The proposal says:

It would be possible to support multiple error types, e.g.,

func fetchData() throws(FileSystemError, NetworkError) -> Data

However, this change would introduce a significant amount of complexity in the type system, because everywhere that deals with thrown errors would have to deal with an arbitrary set of thrown errors.

A more reasonable direction to support this use case would be to introduce a form of anonymous enum (often called a sum type) into the language itself, where the type A | B can be either an A or B. With such a feature in place, one could express the function above as:

func fetchData() throws(FileSystemError | NetworkError) -> Data

Trying to introduce multiple thrown error types directly into the language would introduce nearly all of the complexity of sum types, but without the generality, so this proposal only considers a single thrown error type.

[frogcjn]

Yes. Thanks for pointing out. Without Union type (or sum type), the typed error means nothing for most developer using cases.

[jrose (Jordan Rose)]

I’ll repeat the argument from the original proposal discussion against this: if you throw two errors today, how do you know you won’t throw three errors tomorrow? A dedicated enum type (wrapping the two errors in their own cases) can handle this in a source-compatible way*; untyped throws or even a custom protocol can as well, with no claims of exhaustive case matching; but plain old anonymous union types, like tuples, would break callers as soon as you need to add a third possibility.

* …if we get around to adding a frozen/non-frozen distinction for enums in libraries that aren’t using the binary-compatible library evolution mode. Which admittedly is not much less hypothetical than anonymous union types, but is a little more scoped, and anyway the language recommendation is still to prefer untyped errors.

[frogcjn]

I'm pretty sure this accepted SE feature needs a sum type. We'll see when developer or framework team using this typed error feature without sum type, will make a lot of unnecessary enum error types. Declaring and naming these kind of Enums is ridiculous.

[John_McCall]

It sounds like you should just be throwing Error. You don't have to use typed throws just because it was added to the language.

[Dmitriy_Ignatyev]

You can use Either<ErrorA, ErrorB> or similar OneOfThree<A, B, C> enum for ability to throw two / three Error Types. Does it cover your cases?

[Jeehut (Cihat Gündüz)]

@frogcjn

Without Union type (or sum type), the typed error means nothing for most developer using cases.

I kindly disagree. Most developers use enums for errors already today. And for good reason. No union or sum type needed. Predictable, nice, and easy.

To convince people, you would need to show us practical examples where an enum or any Error does not work and where what you ask for would be much better.

[Jon889 (Jonathan Bailey)]

If a new error is added to the union, then when updating the library won’t there be a compilation error where the errors are caught? So the library user just has to update their code as expected? Or am I missing a point here?

[jrose (Jordan Rose)]

That’s not “source-compatible”; you’d have to release a new SemVer-major version to make that change and not mess up existing clients. It’d be fine within a single package, though.