Dave Thomas says, "We know that we make mistakes all the time. Our compilers, our computers, our applications, and our users tell us we make mistakes. So why shouldn't we learn that lesson of history, and account for mistakes up front?"

Read this Artima.com interview with Pragmatic Programmers Dave Thomas and Andy Hunt:

http://www.artima.com/intv/defense.html

Here's another exerpt:

Andy Hunt: There is an interesting parallel in woodworking, which I do as a hobby. A woodworking magazine recently had an article suggesting that how a woodworker deals with mistakes is what differentiates a master from someone who's not. Everyone makes mistakes: You cut something too short; There's a crack in the board; Something goes wrong. Do you have the skill to work with the mistake, to get beyond it? Or are you just dead in the water and you have to start over?

Dave Thomas: That analogy is a good one. When you're working with wood and you make a mistake, you have to decide, "Do I go on with this? Or do I stop and go way back, fix the problem, and start again?"

Andy Hunt: Is it salvageable?

Dave Thomas: Right. And that's something developers would do well to think about.

What do you think of Dave and Andy's comments?

> What do you think of Dave and Andy's comments?

Spot on. I was glad to read the comments on "Crash Early"; at a recent project I saw catch blocks like this

...
catch (Exception e) {
    // will never happen
}

I said, "Since its never going to happen, why not put a System.exit in the catch block in this critical code?". People weren't so sure then :-) So we designed a mechanism for graceful shutdown.

Another thing we did which paid off big time was to go further than assertions and use class invariance in our domain model. When something went wrong we knew exactly where, why and who caused it. Furthermore, testing the invariance of objects passed to methods gave further protection.
This sounds like a lot of work but its actually a lot less work than finding and fixing bugs. Furthermore, it gives added confidence when refactoring in a similar way to unit tests do, you're testing the running system.

As Dave said "The reason you crash early is to stop errors from propagating far away from the cause.". I beleve this applies to assertions and invariance too - catch the problem before it pops up later in some bizarre way.

Channing

A long time ago, I was working on an interactive student-registration system, the specs for which I was evolving by interviewing the only person who knew how the then-current manual system worked. At one point, she told me something like "When you look up this field in the database, its value will always be A, B, or C." I asked "What should the system do if it's something else?" Her response: "It doesn't matter what the system does, because that can't happen."

So my next question was "All right then -- if that case ever happens, I'm going to make the system delete the entire database and stop anyone from registering ever again. Is that acceptable?" She was aghast: "You can't do that; it would be a disaster!" "But you just told me that that case can't ever happen, so what does it matter?"

After that, we were able to have a more reasonable discussion about how to handle this "impossible" case.

:-)

I have often felt the
need for a <code>ShouldNeverHappenException</code> in Java.

:-)

It's nice to see _somebody_ who still cares about this. So many of the Internet worms and root exploits and similar security disasters we've been seeing are because programmers are blindly trusting input from the outside world without doing some kind of sanity-checking first. Yet that's just about the first lesson I got taught in CS100 in college, along with "Always comment the code so it's readable" and "Here's how to make the PL/I equivalent of HelloWorld compile and run." Our programs had to do something appropriate when given invalid input, and our instructors were quite malicious about designing input to exercise off-by-one bugs and buffer overflows and bogus-values and such. By contrast, the PL/C compiler/runtime also tried to detect overflows, out-of-range numbers, divide-by-zero, etc. and do something to allow the program to continue running with incorrect data, so that debugging runs could find as many bugs as possible per batch punch-card run.
<p>
As far as wood-working goes, I once helped build a church, on a construction project led by a bunch of retired southerners. The younger folks could swing their hammers a lot faster, but the old guys seemed to get a lot more done, and they'd always be saying things like "Well, this wood's a bit wet, so it's going to warp some, so you want to put the nail right there and give it a medium-hard whack on the top to get it into the right place." It's a lot easier to build things when all the raw materials are perfect, but it can be a lot more efficient to know what to do when they're not.