Context: JuliaLang/julia#60344
Since we already have exceptions in Julia with the try-catch mechanism, adding something like this which is similar to but works different from them adds cognitive burden on the user. I think the gain here outweighs that, but it's worth minimizing that burden and not accidentally adding to that in design decisions and communication: For eg., Except{...} syntax or an except keyword would be misleading or at the least unnecessarily confusing.
This feature neatly separates expected error types from truly exceptional, unexpected errors, and reserving the "exception" terminology to only the latter, would let that clearly come through.
The name "declared exceptions" also made more sense in Stefan's original context, but with this (or similar) implementation, "declared error returns" would be a better name: despite Exception being the supertype for these error return types, it's useful to clearly distinguish between this mechanism of return-values-as-errors and the existing try-catch exception mechanism, and avoid conflating the two in the user's mind as much as possible.
The return type going from ::Float64 or ::Union{Complex{Int}, MyObj{Baz}} to ::Except{Union{Complex{Int}, MyObj{Baz}}, Union{DomainError, ...}} feels like a tangible downgrade, in that the significant information that is the main return type is now pushed further away and nested in, becoming less pronounced and much less obvious at a glance. ::T except DomainError avoids that but has the above mentioned communication problem. I'm in favour of using syntax here, eg. ::T ?:DomainError or whatever is available and fits well. Even ::T else DomainError seems meaningfully fitting, while reusing an existing keyword (instead of new syntax or keyword).
match?-end? borrows too much from the weirdness budget in my opinion, and is too similar to match despite being a distinct piece of the syntax (and also goes against the meaning of postfix ? that would be applied everywhere else).
Distinguishing normal matches and these error matches by calling them match and errmatch for eg., would make them be clearly and readably distinct at a glance, but at the cost another new keyword.
Making these error matches actually a type of match could be another option, with a match __ as _ syntax:
In match.md, ::a is mentioned as allowed syntax in one of the cases. If we take the (not too unusual) case that you want to only match against different possible types, the syntax for that can be:
match bar as ::
a -> ...
end
(And match bar; ...; end without an as can use only values and destructuring, or still allow ::a if that's deemed worth keeping.)
And match? foo(); ErrorException -> 0; end? can instead become
match foo() as ?: # or, again, whatever is available, and perhaps matching the return annotation syntax
ErrorException -> 0
end
This would reuse another existing keyword and keep each type of match simple and easy to understand.