Now, suppose that there is a certain situation in which there is also an assertion failure as the program is shutting down. Not a big deal, right? There's already been an unrecoverable exception, so what's one more error message? The program is dying and it can't be helped; who cares?
The Cold Harsh Reality: Any failure in your code is a problem, plain and simple. Yes, sometimes you'll just plain run into things your code can't recover from; and sometimes, while recovery may be technically possible, it isn't worth the effort. However, this is not an excuse to get lazy.
That second assertion failure might be a sign of a much deeper issue - and this is especially true in multithreaded programs.
Another problem that can arise is that users don't know which error message is the "real" problem - it may be the first one, or maybe the second one, or maybe both. This can complicate troubleshooting immensely.
Advice: Always understand the root cause of a problem. Once you understand that root cause, you have three options:
- Fix the root cause directly, if possible/practical
- Quietly suppress the issue when it is appropriate to do so, e.g. when the program is already dying
- Document the situation so that it does not confuse users
These are ranked in order of preference - it is always better to have no error (and therefore no error message) than to have a politely worded error message.
Summary: Fail early, but only fail once. Cascading failures are a sign of weak, fragile code, and they should set off major alarm bells in your head.