howell@COMMUNITY-CHEST.MITRE.ORG (06/24/89)
I while back, I posted the following request to the net; attached are
the replies I recieved. Thanks to those that replied! I'm hoping that this
posting might stimulate more discussion on exception-handling issues
(e.g., CLU and "Exceptional C"s language support for denoting potential
exceptions from a unit, or paramterized exceptions...).
Thanks again,
Chuck Howell
MITRE, Mail Stop Z-645
7525 Colshire Drive
McLean, VA 22102-3481
howell@community-chest.mitre.org
--------
From: mcvax!ukc!dcl-cs!aber-cs!pcg@uunet.uu.net (Piercarlo Grandi)
Subject: Exception handling models
In article <8905021917.AA06033@starbase> howell@STARBASE.MITRE.ORG (Chuck Howell) writes:
I'm interested in alternative exception handling models (e.g., Bertrand
Myer's arguments on "disciplined exceptions" in _Object-oriented
Software Construction_) and various idioms & conventions for use with
existing Ada exception handling facilities.
I have long held that exception handling does not exist; an exception is
always the result of a missing case in some part of a program, i.e. the
program not computing a total function wrt its input data domain.
Exception "handling" is just adding in the appropriate places calls to
procedures to define the missing cases; such procedures whould be
dynamically scoped, so that they can be redefined dynamically.
In other words: "raise" should be replaced by a call to a dynamically
scoped procedure; dynmically scoped procedures should be added to the
language (a trivial exercise).
The issue of non local control transfer, which in the present exception
handling facility is wrongly and inextricably tied to exception handling,
should be provided as an orthogonal mechanism, as not all exception
"handlers" want to terminate with a non local goto, and not all uses of non
local gotos are in exception handlers.
I have posted a few months ago in comp.lang.c++ a C++ class that implements,
using constructors and destructors, dynamically scoped procedures as
exception handlers. It cannot be done as easily in Ada, without changing
the language a bit.
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
----------------------------------------------------------
Return-Path: <tom%prg.oxford.ac.uk@NSFNET-RELAY.AC.UK>
Date: Mon, 12 Jun 89 12:23:23 bst
From: Tom Thomson <tom%prg.oxford.ac.uk@NSFNET-RELAY.AC.UK>
To: howell%starbase.mitre.org@NSFNET-RELAY.AC.UK
Subject: Exception Handling Models
Two aspects that I care about:-
i) have to have containment, so that I can correct the error locally (inside
abstraction where it is detected) and avoid passing the exception to my
user; but have to be able to pass exceptions on where appropriate.
ii) separate the tasks of providing diagnostic information (eg trend information
for preventative maintenance/component replacement) from those concerned
with containment and recovery (eg correcting a single bit failure in a store
with hamming codes, as opposed to logging the occurrence); the latter can do
without being cluttered up with the former, and the former may need to be
switchable independently of the latter.
At a slightly more aspect level of modelling, I believe strongly in in-line
exception handling. However this requires a language with a really good type
system (so that the values arising from exceptions can be typed) with much
type checking at run time, including the ability for code to discriminate on
the type of the data it's operating on. There was some work on this in the
Alvey Flagship project - - ICL & IC put exception values into the functional
language HOPE+ but it was never really taken very far or exploited much.
-----------------------------------------------------------
Return-Path: <emery@aries.mitre.org>
Date: Sun, 7 May 89 19:39:17 EDT
From: emery@aries.mitre.org (David Emery)
To: howell@starbase.mitre.org
Subject: Re: exception models
Cc: emery@aries.mitre.org
i've often wished for exceptions with parameters (and exceptions AS parameters,
but that's another story)). The basic model would probably not 'hurt' the
language, but would trash implementations.
here's some syntax ideas:
raise an_exception(param => value);
when an_exception =>
if an_exception.param = value then ...
declaration syntax is a bit messier...
an_exception : exception (param : its_type);
dave
-------------------------------------------------------------------erickson@LIBRA.CS.NPS.NAVY.MIL (David Erickson) (03/07/91)
I have a few questions related to implementation of exceptions in Ada: Can I assume that any block with an exception handler will require an activation record at run-time (as will blocks with declarations, procedures, functions and packages)? Exception handling appears to be inherently inefficient, since the entire dynamic chain may have to be searched, checking each activation for an appropriate handler (including activations which have no handler). Are there any optimizations which are normally used to improve this search process? Since exception declarations obey static scoping rules, but the search for exception handlers follows dynamic links, an exception can go out of and back into scope (see Barnes pg. 181 for an example). How are names resolved in such a way that two exceptions with the same name, declared in different parts of the program, do not get confused? I would also appreciate any references to articles which address Ada implementation issues. -Dave Erickson
jcallen@Encore.COM (Jerry Callen) (03/07/91)
In article <9103061724.AA02582@libra.cs.nps.navy.mil> erickson@taurus.cs.nps.navy.mil (David Erickson) writes: >Can I assume that any block with an exception handler will require an >activation record at run-time (as will blocks with declarations, procedures, >functions and packages)? No, you can't assume that; it depends upon the implementation. Every compiler I've worked with imposed no runtime overhead for entering and leaving the scope of an exception handler. This is done by having tables (organized in various ways, depending upon the implementation) that relate a range of addresses with exception handlers. The pc is used to search the tables. >Exception handling appears to be inherently inefficient, since the entire >dynamic chain may have to be searched, checking each activation for an >appropriate handler (including activations which have no handler). It's possible to do this checking very quickly and combine it with unwinding the stack. But, yes, you do have to pay for exception handling when an exception occurs. >Since exception declarations obey static scoping rules, but the search >for exception handlers follows dynamic links, an exception can go out of >and back into scope (see Barnes pg. 181 for an example). How are names >resolved in such a way that two exceptions with the same name, declared >in different parts of the program, do not get confused? The "thing" that represents an exception is (in all the compilers I've used) not the exception name itself, but rather the _address_ of a string containing the name. Identical names are represented by multiple copies of the name string; since the addresses are different, there is no confusion. >-Dave Erickson -- Jerry Callen jcallen@encore.com