4 ms·

> Catching the root exception is not a bad idea. If you had caught the new exception what would you have done with it? Something relevant to the error conditio

by simias 3y ago

> Catching the root exception is not a bad idea. If you had caught the new exception what would you have done with it? Something relevant to the error condition, probably? There may be some cases where the total set of possible errors is too large to meaningfully handle every one of them specifically (for instance if you call a high level GPU initialization routine that can fail in a myriad of ways) but that's not true in all cases. Maybe the new error was in fact recoverable, or maybe it calls for some more specific diagnostics. At any rate I completely agree with the parent that changing the set throwable exceptions should be considered a breaking API change and should be enforced by the compiler. If an API method wants to future-proof and be able to throw anything, it can declare just that and everybody will know to expect the unexpected. That's why I vastly prefer Rust's Result<> system which does most of what exceptions do and with fairly similar ergonomics but with normal return values and all the type checking that it involves.

scarface_74 3y ago
> Something relevant to the error condition, probably? And in every language I know you can have catch blocks for specific errors and then have a generic catch all.
- simias 3y ago
  The ability to catch exceptions is not the issue, it's knowing what to do once they're caught that's the problem. The parent apparently had exhaustive exception handling, catching all cases. A new exception is now generated, probably signaling a new error condition, you can't expect the calling code to be able to handle it gracefully. Hence why a compile error might be a better solution here, the coder could decide whether the new exception can fit an existing handler or requires special handling.
saurik 3y ago
Realistically speaking, you should essentially never try to "handle" errors with tricky program logic: propagate them up (automatic in languages with exceptions) and eventually--in as few places as possible--report them to the user so the user can decide what to do, not the code.
- simias 3y ago
  I disagree, low level exceptions rarely make sense on their on for the users, the automatic propagation of exceptions just promotes laziness by having a catchall "print(exception); exit(1);" at the top level. If you're lucky you get a proper stack trace that lets you figure out what's going on, but even that is poor ergonomics. A high level library should report high level exceptions for instance, not minute details of the lower layers. Nothing is more frustrating that having a program fail and all you have is some cryptic "No such file or directory" or "Operation not permitted" error that doesn't tell you what the code was actually trying to do or give you any hint on how to fix it.

by simias 3y ago

scarface_74 3y ago

> Something relevant to the error condition, probably? And in every language I know you can have catch blocks for specific errors and then have a generic catch all.

simias 3y ago
The ability to catch exceptions is not the issue, it's knowing what to do once they're caught that's the problem. The parent apparently had exhaustive exception handling, catching all cases. A new exception is now generated, probably signaling a new error condition, you can't expect the calling code to be able to handle it gracefully. Hence why a compile error might be a better solution here, the coder could decide whether the new exception can fit an existing handler or requires special handling.

saurik 3y ago

Realistically speaking, you should essentially never try to "handle" errors with tricky program logic: propagate them up (automatic in languages with exceptions) and eventually--in as few places as possible--report them to the user so the user can decide what to do, not the code.

simias 3y ago
I disagree, low level exceptions rarely make sense on their on for the users, the automatic propagation of exceptions just promotes laziness by having a catchall "print(exception); exit(1);" at the top level. If you're lucky you get a proper stack trace that lets you figure out what's going on, but even that is poor ergonomics. A high level library should report high level exceptions for instance, not minute details of the lower layers. Nothing is more frustrating that having a program fail and all you have is some cryptic "No such file or directory" or "Operation not permitted" error that doesn't tell you what the code was actually trying to do or give you any hint on how to fix it.