Error messages, and the virtue of failing safely

What a system says when it breaks, and what it does, are two separate design decisions.

When something fails, a system tends to want to explain itself. That instinct is right for the people maintaining it and wrong for everyone else. A detailed explanation of internal structure is genuinely useful, but it should travel to the record kept for maintainers, not to the visitor's screen. The visitor needs to know that it failed, whether to try again, and how to get help. A reference they can quote gives them everything they need while giving away nothing else. Two audiences, two messages, one event.

Failing safely is the broader idea and the more important one. Every system fails eventually: a dependency is unreachable, capacity runs out, an assumption stops holding. The question is not whether but what happens next. A system that fails safely refuses the action rather than half completing it, leaves stored information in a state that still makes sense, and defaults to denying access rather than granting it. A system that fails open, granting access because the check could not be completed, has arranged for its worst moment to coincide with its weakest defence.

This is why an ordinary looking system that stops cleanly is worth more than an ambitious one that has never yet stopped. The first has been designed with its own failure in mind and will behave predictably under pressure. The second has only been lucky, and nobody knows what it will do, least of all the people who built it. Assume failure, decide in advance what it should look like, and the bad day becomes an inconvenience rather than an event.