Is that a startup or a terrorist cell?
In a way, the traditional edit-compile-test-debug cycle is a "deploy-only" development style. The "continuous integration" part of extreme programming is taking that even further.
Imagaine for a moment what it would be like if during every second of work during every day of the week each and every thing you did was accompanied by a corresponding design exercise along the lines of "okay, but what if it crashes right then." Now that would sure produce some "software with good error handling", now wouldn't it. That is crash-only software.
In complex systems, there's always the assumed potential for untoward behavior from unanticipated recovery environments; the handling of recovery can be a bigger problem than a complete failure.
In these environments, clean failures are preferable.
And staging the recovery processing can be preferred. This goes as far as staging application start-up and sequencing the component server reboots manually. Yes, manually.
E.g. there's a terrific comment over on Snarkmarket that talks about gliders, and how they are, in a sense, always crashing.
However, glider pilots perform that skill every flight. From the moment of release and throughout the flight, they’re constantly planning ahead, thinking of where the landing spot will be (and some alternates) and what flight path will get them there."
Anyway, it deserves to be re-submitted in any case.
I think that's also where the notion of error handling comes into play because it's obvious at that level that it's not enough to just handle exceptional cases gracefully inside the body of your main program(s), and in fact, you may not want to, you may want to let certain things percolate up and cause the process to exit, if only to achieve a uniformity in how you handle edge cases.