R. Clayton (rclayton@clayton.cs.monmouth.edu)
(no date)
What do you have to say about checking for errors in our code?
This is probably something we should take up in class some day. My opinion
(and practice) on error checking is controversial: I believe everything
(preconditions, postconditions, and invariants) should always be actively
checked, and that errors detected should cause immediate termination.
If we actually code error checking into our code it goes against the dictum of
simplicity, but it protects the program against bugs and other nasty things.
I'm not sure I follow your reasoning. Of the four criteria ep uses to define
simplicity, the first and most important one is that the system must clearly
indicate its intent. It seems to me that one of the clearest statements of
intent is a test for proper behavior for code, or proper state for data.
For example in our task we accept a date as an input parameter. Let us say we
accept three parameters yy, mm, dd The simplest thing to do would be to do no
checking, that is that do not check that mm is in [1, 12] or that dd is in [1,
days[mm]}, on the assumption that whoever has entered the date into the system
in the first place has checked, this is fine - except what if it hasnt been
checked?
O.k., the routine that doesn't check the date data is simpler (by some
criteria, perhaps code size) than the routine that does check the data.
However, ep considers the checking routine to be simpler, because its intent
(at least with respect to the state of the data) is clearer than the
unchecking routine's intent:
void f(int yy, int mm, int dd) { . . . }
vs.
void f(int yy, int mm, int dd) {
assert((1900 <= yy) && (yy <= 2100));
assert((1 <= mm) && (mm <= 12));
assert((1 <= dd) && (dd <= 31));
}
Dates are a bad example because properly checking dates requires a lot of
non-simple work, but even these simple-minded checks should get the intention
across.
I see that the entire project is under myy ownership and I should look over all
the code in the entire project and 1: make sure that the data is checked for
errors when it first enters the system. 2. Make sure that it is checked nowhere
else?
That's the system designers' choice. I disagree with it (redundancy is a
small price to pay for insuring system integrity), but I realize I'm in the
minority with this philosophy.
I know that in my office the rule is that the one who notices the bug has the
responsibility for fixing it, but I dont think that is quite the way to go.
That rule squares with the ep philosophy of communal code ownership and
everyone's full responsibility for everything.
This archive was generated by hypermail 2.0b3 on Thu Aug 02 2001 - 12:45:05 EDT