Introduction object-oriented programming

[Mike Meyer]

Peter Hansen <peter at engcorp.com> writes:

> One small example of an area that bothers me -- not even related to 
> unit testing -- is the comparison under the subtitle "But isn't 
> defensive programming good thing?" (sic).  It shows the DbC approach 
> as doing exactly what we often recommend *not* doing in this 
> newsgroup: attempting to verify a condition exists prior to actually
> performing the operation that requires that condition.  The
> so-called "defensive" programming version (I would have used that
> term for the DbC version, but maybe "defensive" has a reserved
> meaning in DbC for all I know) shows the more Pythonic approach of
> just performing the operation, then catching the exception if
> one occurs.

You're seeing the difference between Python and a compiled language
that's not as dynamic. If you're writing Python, you're absolutely
correct.

In a language with strong compile-time checking and little or no
run-time checking, you want to get the Python behavior. However, you
can't rely on the run-time checking to do that for you. In the
example, writing beyond the end of the stack because it's full may
well just overwrite memory. So you add a precondition to the contract
to catch that - and *that* raises an exception that you deal with.

Even in the case where the underlying array would raise an exception,
it can be argued that the implementation shouldn't be exposed to the
client. The client should see a StackFull exception, not an IndexError
exception. DbC would provide the former.

        <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.