Path: news.daimi.aau.dk!news.uni-c.dk!newsfeed.sunet.se!news00.sunet.se!sunic!news.sprintlink.net!news.up.net!news.mtu.edu!newsxfer.itd.umich.edu!newsxfer2.itd.umich.edu!newsfeed.internetmci.com!tank.news.pipex.net!pipex!howland.reston.ans.net!news-e2a.gnn.com!newstf01.news.aol.com!newsbf02.news.aol.com!not-for-mail
From: jsarkela@aol.com (Jsarkela)
Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
Subject: Re: What Should An Exception Handling Do? -- Clarification of rules
Date: 9 Apr 1996 12:01:29 -0400
Organization: America Online, Inc. (1-800-827-6364)
Lines: 71
Sender: root@newsbf02.news.aol.com
Message-ID: <4ke1kp$pem@newsbf02.news.aol.com>
References: <31647113.13BD8C66@cygnus.com>
Reply-To: jsarkela@aol.com (Jsarkela)
NNTP-Posting-Host: newsbf02.mail.aol.com
Xref: news.daimi.aau.dk comp.object:53931 comp.lang.eiffel:22709 comp.lang.c++:177611 comp.lang.beta:10715 comp.lang.java:32565 comp.lang.sather:12429

Just recently joined the thread, here is my point of view.
Quoting a base definition of this thread, exceptions are...

> The definition:
> 
> >       "Exception handling is intended to allow code that has
encountered
> >a condition it cannot cope with to return to some other code that
> >directly or indirectly invoked it. There is no way for an exception
> >handler to request the thread of control to resume from the throw
point.
> >In other words, "throw" implements the termination model of exception
> >handling."     -ARM, Ellis & Stroustrup, page 354
> >

As an Eiffel and Smalltalk programmer, I find that viewing exceptions only

as, I can't cope situations, is a limited point of view. Consider
contracts.
A contract describes a meeting of minds between a client and a supplier.
The nature of the agreement is that it is observable, verifiable and
enforceable. If either party determines this agreement has been violated,
then the service provider and consumer should enter arbitration to resolve
the dispute. The exception handler serves as the arbitrator. Note that
VisualSmalltalk models exceptions as objects allowing handlers to be
associated with the call chain resolving from most recent call site to
most remote, but also to associate arbitration code with the exception
object itself as a default handler. (Note, many exceptions may be handled
by the default handler in the exception object and resume subsequently on
the thread which raised the signal.

In the case of a real "error", then resumption is almost certainly not a
good idea. Resumption semantics become more compelling when an event may
arise calling into question conformance with the agreement forged in the
contract but which in fact is a false alarm.

Real world case in point. Imagine a fictious object runtime which must
have one binary support the range of operating systems with the interface
identified as Win32. Under Win32s many file operations will return an
error code 87 when in fact Windows95 or Window NT will give a notification
code with more meaning. on the Win32s platform an error code 87 may
indicate a dire consequence or merely be an informative notification.
Structuring the File System framework to use exception handlers can allow
an 87 error code to raise an exception and let the arbitrator determine
the settlement of the outcome. That is to say, is this a trivial
notification? Or, is this a serious error condition. In the first case, we
may resume. In the second, we must take direct alternative action.

Contracts are binding agreements. Binding to an operating system interface
requires us to acknowledge that many implementations of the same interface
may have varying degrees of robustness (and unfortunately semantic
correctness). It is my experience that one collaboration model may serve
as a common design for multiple host platforms. However, each platform
will  raise it's own set of issues, often requiring platform specific
resolution. The resolution of the exception state in this modern age might
depend on platform rather than call stack state. As such, perhaps an
objective view of exceptions is required. A view in which the client,
supplier and exception handlers comprise the principle state of the
exceptional situation and the state of the call stack at the time of
exception is the history that the parties bring to the table for
arbitration.

The Visual Smalltalk Team programming environment makes heavy use of
exceptions not only to signal errors, but also as a notification
mechanism. This is a simple and direct abstraction to use, and more
closely models the programming as contracting principles.

-- John Sarkela     jsarkela@aol.com
-- My views are my own and not those of employers past or present.
-- Well, my jobs have profoundly imprinted a point of view.