> the interface making assumptions about the implementation details of every potential implementation.
No, as you'd force the implementation to catch their implementation specific exceptions and rethrow them in the way defined by the interface.
That's really the crux of it, when I call foo(), I expect to see a FooException when something goes wrong, since that's the only one I can meaningful react to. If I get an ImplementationDetailException that I never heard from and that isn't specified in the interface, how am I supposed to react to that in a meaningful way?
If exception are supposed to be used for error handling, you have to actually report and handle them in a well specified manner, you can't just treat them as a slightly less crashy version of a SIGSEGV.
Unless the language does that for you (both enforcing it, and providing tools to make it absolutely trivial), it will never happen, it's just way too much overhead to have to define a new exception for every method in an interface, then a sub-exception for every method in the implementation of that interface, then go through the internal conversions from the underlying exceptions to the parent one.
People can't be arsed to do that in Rust where there's ways to abstract over those things and macros to define them.
If that's the route you assert is necessary, you need something like Zig's errors.
I agree that, if you are working with checked exceptions, that’s certainly better than adding garbage to your interface.
But for many types of checked exception you just end up wrapping the underlying exception in a foo exception anyway.
I think you are right: if you are using exceptions for error handling, of errors you expect people to actually deal with, this is currently a reasonable (if painful) option to ensure exhaustive analysis of returns — which most people agree is a good thing these days I think, what with mainstream popularization of options etc.
No, as you'd force the implementation to catch their implementation specific exceptions and rethrow them in the way defined by the interface.
That's really the crux of it, when I call foo(), I expect to see a FooException when something goes wrong, since that's the only one I can meaningful react to. If I get an ImplementationDetailException that I never heard from and that isn't specified in the interface, how am I supposed to react to that in a meaningful way?
If exception are supposed to be used for error handling, you have to actually report and handle them in a well specified manner, you can't just treat them as a slightly less crashy version of a SIGSEGV.