

Let it crash (the right way) - edw519
http://mazenharake.wordpress.com/2009/09/14/let-it-crash-the-right-way/

======
ZeroGravitas
_Crash-only software: More than meets the eye_ by Valerie Aurora

<http://lwn.net/Articles/191059/>

From the conclusion: _"Properly implemented, crash-only software produces
higher quality, more reliable code; poorly understood it results in lazy
programming. Probably the most common misconception is the idea that writing
crash-only software is that it allows you to take shortcuts when writing and
designing your code. Wake up, Sleeping Beauty, there ain't no such thing as a
free lunch. But you can get a more reliable, easier to debug system if you
rigorously apply the principles of crash-only design. "_

Also, of interest I believe Snow Leopard simply kills (i.e. crashes) any
software that signals it doesn't have state in order to speed up shutdown.

------
cromulent
I've seen a lot of enterprise-y programs that do this and it just looks lazy.
The poor user enters some invalid input data and the program crashes, and the
developer points at the spec and says "there was nothing in here about
validating and giving an helpful error message".

The assumption seems to be that "ad-hoc decisions" made by the programmer, are
often worse than crashing. I'm not sure that is often true. Who is supposed to
be the domain expert, the person writing the spec, or the developer?

Perhaps asking the spec-writer what should happen in the situation would be
better than just letting it crash. There is a business cost to crashing, and
businesses are normally the ones paying for the software.

------
wglb
This sounds like a good idea. Reminds me of Dan Weinreb's video where he says
that sometimes if your process has too much garbage to collect in a clustered
implementation, that the best thing to do is to just crash.

And in a backhanded way, this relates to "do the simplest thing that could
possibly work" (although I have begun to have some doubts about that
philosiphy).

