4 ms·

Let it crash (the right way)

2 points by edw519 17y ago

wglb 17y ago
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).
cromulent 17y ago
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.
ZeroGravitas 17y ago
Crash-only software: More than meets the eye by Valerie Aurora http://lwn.net/Articles/191059/ 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.

4 ms·

Let it crash (the right way)

2 points by edw519 17y ago

wglb 17y ago
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).
cromulent 17y ago
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.
ZeroGravitas 17y ago
Crash-only software: More than meets the eye by Valerie Aurora http://lwn.net/Articles/191059/ 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.