Miss Dada  🏳️‍⚧️

But seriously, the reasons I see are: - Beyond a local frame, types don't really help "make invalid states unrepresentable" because the way large systems fail is open-ended - Types encourage different representations of the same error, because you end up wrapping them

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