The Artima Developer Community
Sponsored Link

News & Ideas Forum (Closed for new topic posts)
Programming Defensively

5 replies on 1 page. Most recent reply: Jun 13, 2003 6:18 PM by Bill Stewart

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 5 replies on 1 page
Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Programming Defensively Posted: Apr 28, 2003 3:00 PM
Reply to this message Reply
Advertisement
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?


Channing Walton

Posts: 32
Nickname: channing
Registered: May, 2003

Re: Programming Defensively Posted: May 15, 2003 12:49 PM
Reply to this message Reply
> 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

Andrew Koenig

Posts: 10
Nickname: ark
Registered: Apr, 2003

Re: Programming Defensively Posted: May 18, 2003 9:09 AM
Reply to this message Reply
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.

Channing Walton

Posts: 32
Nickname: channing
Registered: May, 2003

Re: Programming Defensively Posted: May 18, 2003 11:34 AM
Reply to this message Reply
:-)

Tasos Zervos

Posts: 17
Nickname: tzervos
Registered: May, 2003

Re: Programming Defensively Posted: May 22, 2003 3:39 AM
Reply to this message Reply
I have often felt the
need for a <code>ShouldNeverHappenException</code> in Java.

:-)

Bill Stewart

Posts: 1
Nickname: billstewar
Registered: Jun, 2003

Re: Programming Defensively Posted: Jun 13, 2003 6:18 PM
Reply to this message Reply
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.

Flat View: This topic has 5 replies on 1 page
Topic: The Art of Unix Programming Previous Topic   Next Topic Topic: How Vienna Escaped the Cubicle

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use