"Defensive" programming and Eiffel/DBC

"Defensive" programming and Eiffel/DBC

[card]

<Sorry if this appears twice; I think I messed up my DejaNews
confirmation.
- Mike>

First of all, I would like to thank everyone on comp.lang.eiffel who
responded
to my "Basic Questions About Eiffel" post. Your responses gave me the
insight
into some Eiffel language features that I was trying to infer from
following
the Ariane thread.

During the Ariane thread, someone quoted Bertrand Meyer as saying,
"Defensive
programming is offensive." I think that an example of what Mr. Meyer was
(supposedly) talking (or writing) about can been seen in this snip from
one of Joachim Durchholz's posts, which was part of a thread about safety-
critical development in Ada and Eiffel:

>If PBC is in place, you don't have to write
>
>  do_something (My_Aircraft: AIRCRAFT) is
>  do
>    if MyAircraft.Mine then
>      -- do something with My_Aircraft
>    else
>      -- declare error
>    end;
>  end; -- do_something
>
>Instead, you write
>
>  do_something (My_Aircraft: AIRCRAFT) is
>  require My_Aircraft.Mine
>  do
>    -- do something with My_Aircraft
>  end; -- do_something
>
>which is shorter, and clearly separates the "defensive programming" part
>from the really useful code.

I agree that the second piece of code above is easier to read as it avoids
an
"error checking" if statement and its associated extra identation. This
seems
*analogous* to Ada's automatic constraint checking. For instance, when I
access
an array in Ada I never have to write:

  if The_Subscript < The_Array'first or else
     The_Subscript > The_Array'last
  then
     raise Constraint_Error;
  else
     -- access the array
  end if;

Ada will automatically raise Constraint_Error if the array bounds are
exceeded,
so I don't need the "defensive" if statement.

It seems to me that Eiffel/DBC extends this concept beyond index/bounds
checking so that it can include object state checking. Just as Ada will
automatically insert range checks where needed, Eiffel will insert the
precondition checks so that they are executed before the corresponding
method (when the method is being called from outside its class, if I
understand this correctly).  Likewise, Eiffel will execute the
postcondition
checks prior to returning control to the caller (again, if the method was
invoked from outside its class). As several from the Eiffel community have
pointed out, these checks are inherited and can be modified in descendant
classes (the preconditions can be weakened by adding the equivalent of an
"or else" and the postconditions and invariants can be strengthened by
adding the equivalent of an  "and then").

However, even with this added capability "defensive" programming cannot be
entirely removed since you still need exception handlers (I would place
exception handlers in the "defensive" category). Still, I think Eiffel's
assertions would make most code easier to read. I am not convinced that
pre/post conditions and invariants can be *effectively* used as a kind of
"executable statement of requirements" in all domains, however. I am going
to address this issue in a separate post/thread.

- Mike

---------------
Michael P. Card
Lockheed Martin Ocean, Radar and Sensor Systems Division
Syracuse, NY 13221
voice: (315)-456-3022  FAX: (315)-456-2414  e-mail:card@syr.lmco.com

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet