Observation: It is tempting to let your software fail in messy ways. For example, consider a case where a fatal exception is thrown from your code. This exception is displayed to the user along with some possibly-useful debugging information.

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:

1. Fix the root cause directly, if possible/practical


2. Quietly suppress the issue when it is appropriate to do so, e.g. when the program is already dying


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