Re: Exceptions as objects (was Re: What is wrong with OO ?)

[jeffries@ic.net (Ronald E Jeffries)]

On 25 Jan 1997 02:07:04 +0000, piercarl@sabi.demon.co.uk (Piercarlo
Grandi) wrote:

>Let's start with the nature of exceptions. The first point is that if a
>procedure implements a total function then it will never have an
>exception.
>
>Therefore exceptions arise only and only if a procedure implements a
>partial function, and arise only and only when the inputs to a procedure
>are outside its domain.

Yes ... and then you go on to make the function more robust, which
would be a good thing when it's practical.  But as you point out, the
exceptions arise when the inputs are out of the range contemplated by
the function as written.  

Exceptions, however, whether represented as objects or long jumps, are
about handling the unexpected.

My application system must keep on going, whether or not the input
routines are prepared to deal with B's in the middle of the numbers,
and dates like 2/31/1997.  Complexity, lack of access to the code,
limited resources mean that the input routines won't ever be made
complete.  And they can't know what their users want done with those
B's and weird dates anyway.

At the same time, when using the input routines, it is impractical
(costly and error-prone) to have every call to the routines check for
errors.  It is much more practical and convenient to choose a standard
place where, if an input error occurs, a default action can be taken.

In a project I'm presently working on, the input routines try to
handle all the errors.  Then when the application definers decided
what kind of notifications they wanted on input errors, we had to go
in and edit the input routines and change them all around to get the
job done.  Had they just thrown an exception, we could have fielded
the exception where we wanted to, and filed our notifications and gone
on.

While complete program correctness is an interesting science, it is
not something that we often attain in practice.  Exceptions are a
simple and practical way to deal with the faults we humans often leave
in our programs and our data.

Regards,

Ron Jeffries
Smalltalker
How do I know what I think until I see what I type?