[naasking]

You're leaking implementation details if you let exceptions bubble. Sometimes this is ok if all of the callers are aware of the implementation details anyway, but it can make refactoring or changing implementations more difficult otherwise.

[wvenable]

You should leak implementation details on exceptions -- if an operation fails because of a network timeout or file access issue, that's useful information. Most exceptions cannot be meaningfully caught anyway so let me log with a good stack trace and be done with it.

[naasking]

The inner, wrapped exception is logged. Leaking exception details can also leak privileged information, and if you're not careful this can leak information to attackers too. More information is not necessarily better.

[wvenable]

If your error logging is leaking privileged information to attackers that's a completely different problem from what you should do in code when throwing exceptions.

Wrapping exceptions to remove information is mostly a pointless exercise. You should be doing it only to add additional context.

[naasking]

It's not a different problem, my whole point was that letting exceptions bubble is not a universally acceptable policy. Sometimes you want to bubble, sometimes you want to wrap, and sometimes you want to wrap with information hiding to avoid leaking information.

[wvenable]

> my whole point was that letting exceptions bubble is not a universally acceptable policy.

It should be. It should bubble to whatever boundary you have (web API, event loop, etc). At that boundary, if it's not supposed to leak information then don't. Do whatever sanitation you need at one point only. Good use of exceptions should have as few "catch" blocks as possible.