Hacker News Reader

Comment by PretzelPirate | Hacker News Reader

Wouldn't it still be a problem? By putting "throws [Exception List]" in the interface, the interface making assumptions about the implementation details of every potential implementation.

The interface can't know every exception that an implementation might throw, and using your example, some implementations may not use IP at all and won't throw those exceptions.

It seems like you'd end up needing to list every possible exception on "foo() " when defining the interface, and then handle every possible exception in any code that uses "ExampleInterface".

At that point, it would be better to not annotate exception information at all.

View on HN

> 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.

What you are saying is that people can't be arsed to do proper error checking, which is absolutely true.

Making a sane hierarchy of exceptions is the smaller of the problems of actually handling them everywhere.

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.

Exceptions should absolutely be a part of an interface and it stops you from leaking implementation details. If I have an IRepository interface then none of the methods should ever throw SqlException, HttpException, or anything like that. You'd map them to something else. Exceptions in most languages are implicitly part of the contract, and not having consistent ones on an interface breaks Liskov's Substitution Principle.

As others have pointed out, my example would have been better if it said `ExampleExceptionFoo, ExampleExceptionBar` to more clearly indicate that an interface would define what exceptions it could throw as part of the contract. Individual implementations could extend those base exceptions if they need to.

There is not much difference between this and using error types, except the syntax sugar.

Reply on news.ycombinator.com