On Thursday 19 June 2003 14:59, Michael wrote:
> --- Greg Stein <firstname.lastname@example.org> wrote:
> > It isn't just Subversion. APR, APRUTIL, and Apache httpd also use this
> > convention. "Give me good inputs, or I'll crash." The crash is actually
> > quite nice because we can use a traceback to figure out the codepath
> > which
> > contains the problem.
> Indeed. Some people (like Bertrand Meyer) go to great lengths to convince
> people to code this way. You have his design by contract -- if you
> promise to call my routine with the precondition satisfied then I, in
> return, promise to deliver a final state in which the postcondition is
> satisfied. Then you have his non-redundancy principle -- under no
> circumstances shall the body of a routine ever test for the routine's
I don't think that the code mentioned here was written as you are stating it
was. The precondition of (name!=null) *is* being test for and being acted on.
Only thing is that it is done implicitly (by letting the strlen call blow up
on the derefence) by design.
I didn't mean to start a long-winded thread on this subject (it started
strictly from my ignorance of design decisions made for subversion), it's
only that I grew to a different mantra: "be liberal in what you receive and
strict in what you send". I tend to catch everything in my code (even if only
to spew a message and then blow up) because that makes the intent
unambiguous. As it stands, if one only looks at the svn_stringbuf_set
function one can't determine if NULL is not being handled by design or error.
Given my coding practices I assumed error when it was design in this
> If you violate the precondition then get can expect bad things -- like
> core dumps.
If you're not testing (explictly or not) for the preconditions I'd say that
you're very lucky if you get a core dump. Testing preconditions has avoided
many sleepless nights looking for bugs that exhibit random behaviour in my
life. The reason I know that is that I have lost many sleeples nights looking
for bugs that would have been avoided by testing for preconditions ;-)
> Of course all this assumes the contract with the user is clearly spelled
It also requires that anyone getting into an existing project learn all of
the contracts between all of the subsystems before they can touch any code.
It also requires multiple teams working on multiple parts of the system to
have much more intimate knowledge of all the interfaces. That is a very
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Jun 20 01:46:18 2003