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

["John W. Sarkela" <jsarkela@enfish.com>]

Piercarlo Grandi wrote:
[...]
> But really the biggest problem of the mechanism is that it presents as
> something complicated and special, to the point of requiring its own
> control structure, chapter in the book, papers, and so on, what is an
> entirely simple thing, as long as one presents it as: dynamic scope
> +optional control transfer.
I would advance the argument that the nature of the most appropriate
exception mechanism will vary as one adopts procedural, functional or
object oriented points of view. 

As an example of why I think objects modeling exceptions are right, I
would use the point of view first expressed to me by Bertrand Meyer,
programming by contract. Using the exception mechanism with which I
am most familiar, Visual Smalltalk's.

In human interaction, a contract is a document that describes a promise
of service to a client. A contract has three important qualities.
  1. It is observable by client and supplier.
  2. It is verifiable by client and supplier.
  3. It is enforcable by client or supplier.
When either the client or supplier detects that the terms of the
contract
have been violated, the situation is sent into arbitration for
resolution.

In my programs exactly the same holds true. When assertions about the
state
of execution have been violated, I create an instance of an exception
that
models as carefully as possible all of the information about the
observed
violation of specification. Thus, from an object modeling perspective,
the
exception object serves as the court of arbitration for disputes between
clients
and servers.  Handlers may be set associated with method activation
records.
Each handler serves as a local arbitrator for the signaled exception. If 
recovery is not possible, the dispute may be passed to the next higher
authority.
If none are found, default rules may be handled by the exception object
itself.

I have found this model of exceptions and their handling to be both
intuitive
and effective. The fact that non-local control transfers occur is not
really
a problem conceptually, because the control unwinds the chain of
activations
that led to the exceptional situation in the first place.

This is a rational, structured, normal handling of exceptions in an
object
model. If I were using a functional language, then total functions would
be a more appropriate point of view. However, for an object oriented
language
exceptions as objects provide a rich implementation mechanism for
supporting
the design notion of programming by contract.

John Sarkela
jsarkela@enfish.com