I feel like sometimes software could benefit from a better conceptual differentiation between failures and errors. Failures happen, and robust software should

I feel like sometimes software could benefit from a better conceptual differentiation between failures and errors. Failures happen, and robust software should deal with them in a predictable manner. Not all software needs to be able to recover from failures automatically, but they should remain in a consistent state so that an operator can fix the situation, allowing the system to recover. A database system unexpectedly going down is a failure, and a system that expects it will never happen can't be considered correct. Errors are the result of a mistake: Either there's an invalid input from the user, or a bug has caused data corruption. Errors can be detected with defensive coding (eg. by validating input), but often systems can't recover from errors, so they to be communicated to the user. You'll want systems to abort their current task if they encounter errors, as the state will be undefined, and continuing may make the situation worse.