3 ms·

This is interestingly divergent from the advice given in “Philosophy of Software Design” by John O. which is “exceptions are most useful when they're thrown the

• Scarblac 3y ago
  Note the comment you reply adds "this might be the majority of cases". There are exceptions that are a normal result of some function call, and they can be handled by the caller. But most exceptions are of the kind that you want to pass to some general error reporting thing far away.
• diarrhea 3y ago
  Funny you’re mentioning that exact book. I almost put it as the source in my original comment, but maybe I remember wrong. What I remember is the “deep interfaces” advice, which is great. It encourages small surfaces but deep implementations. Hiding the potentially large list of raisable exceptions helps in keeping an interface or API small. Errors are handled transparently and the user only needs to deal with those they know how to handle. What good is it to raise a deep error that by the time it reaches the top levels (like a web servers middleware loop), it can no longer be handled reasonably and has to be thrown? That’s why, if you can handle it, do so ASAP. That’s what I remember from that book. Again, perhaps I’m misremembering.
• MereInterest 3y ago
  I don’t think the pieces of advice contradict each other. If exceptions are handled at the lowest scope possible, and exceptions are most useful when the rise above many scopes, then exceptions are most useful when the scope that encounters the error is very deep compared to the scope that can handle the error. This agrees with my intuition, that error codes are most fragile when they must be checked and re-raised across many scopes.