Miss Dada  🏳️‍⚧️

Empirically, Java tried it and programmers did everything in their power to squirm out from it

Yeah but I don't think that was a fault of typed errors, it was a fault of how their type system interacted with it. If an interface let implementors state what errors they could return, that would fix most of the issues. TBH I don't know how to make it work well with inheritance

I think the biggest thing that Rust folks have zeroed in and agreed on is that typing is more important for libraries than applications. Libraries should return enums of their errors and give applications a chance to recover, apps usually just need a `Box<dyn Error>`

Interesting, I would've expected the opposite. Libraries returning enums of their errors means they can never grow new errors without breaking clients

You can mark an enum as non-exhaustive, which requires any `match`es outside the crate to have a default branch

For errors that's pretty much always what you'd do anyway, since if consumers care about any of your error variants it's probably only only one or two

Nice, swift enums have the same functionality. However, at that point it seems to me the specific error type isn't doing much for your clients

Depends on the context. Diesel has an error variant for "this query was expected to return 1 or more rows, but zero were returned" for example which is commonly handled. Really the point is more than if your consumers can recover from a specific case, don't take the choice away