Re: Pre-condition vs. Post-condition

[jls@rutabaga.Rational.COM (Jim Showalter)]

>1) Refering back to Kernighan & Plauger's "The Elements of Programming
>Style," I'll quote another rule:

>"Write clearly - don't sacrifice clarity for 'efficiency'."

Is this Kernighan of Kernighan & Ritchie? (If so, he doesn't follow
his own advice.)

>2) Ok, so you think that the second version of Pop is faster
>because it is not doing the test.  Well there may not be an explicit 
>test, but there sure has to be an implicit one.  The compiler has
>to generate code to test to see if a constraint error needs to be
>raised, i.e. there is run time checking going on here.

Yes, but the checking doesn't have to involve the overhead of a context
switch, as is required in your version with the call to another
subprogram. So my version is still faster, even with the checking.

>>Not only is it faster, it is safer, since
>>without using tasks you cannot guarantee that between the time you
>>checked and the time you popped it hadn't been popped elsewhere. 

>The examples given were for the sequential world, there was no
>mention in the original posting or my follow up about tasking.

Yeah, but if you do it right the first time, migrating to the
parallel world isn't a maintenance nightmare.

>I don't think the follow up poster has really come up a with good
>case.  His/her case is mainly based on efficiency concerns,

Well, I didn't make the case, but I actually think the version with
the exception is at least as easy to understand as the first version.
In this particular case the distinction is not as great, but consider
the classic "if/then" checking that is performed in languages without
exceptions:

      begin
	if some_precondition and then
           some_other_precondition and then
           yet_another_precondition then
              do_what_you_really_wanted_to_do;
        end if;
      end;

Contrast this to the exception version:
     
      begin
        do_what_you_really_wanted_to_do;
      exception
        when this_problem_occurs =>
          take_corrective_action;
        when that_problem_occurs =>
          take_other_corrective_action;
      end;

I argue that it is far easier in the exception case to figure out
what is supposed to happen, and that the reader can skip all the
error handling/checking stuff if he/she is just interested in the
main control flow. I've seen code written with so much precondition
checking that finding the actual statement that did anything was like
finding a needle in a haystack. With exceptions I don't have this
problem.

Furthermore, consider the use of procedures that raise exceptions
with the intent that they express the preconditions required:

      procedure assert_condition_valid (...) is
      begin
        if not some_precondition then
          raise this_problem_occurs;
      end assert_condition_valid;

      procedure assert_another_condition_valid (...) is... -- Similar.

      begin
        assert_condition_valid (...);
        assert_another_condition_valid (...);
        do_what_you_really_wanted_to_do;
      exception
        when this_problem_occurs =>
          take_corrective_action;
        when that_problem_occurs =>
          take_other_corrective_action;
      end;

Now in this case, I not only can find what is really being done,
I can also find out what the preconditions are, all without getting
snarled up in N levels of if-then checking. It reads well, it is
easy to maintain, and it depends on exceptions.
--
***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd
ever be able to find a company (or, for that matter, very many people) with
opinions like mine. 
              -- "When I want your opinion, I'll read it in your entrails."