Article View: comp.lang.modula2
Article #3647Exception handling
From: John Lancaster
Date: Fri, 13 Mar 1987 20:38
Date: Fri, 13 Mar 1987 20:38
114 lines
5010 bytes
5010 bytes
> Could we get a discussion going on exception handling in Modula-2? ...
What is an Exception? A exception occurs when something unexpected happens
during runtime. Exceptions can be caused by overflow, range, address errors
or raised by the programmer.
What is an Exception handler? An exception handler is a block of code to
which control will be transferred when the exception occurs. Control is NOT
returned to the point at which the exception was raised. Instead it is
passed to a procedure higher up the call tree and the intervening stack is
discarded. e.g. A calls B calls C calls D. If D raises an exception which
B is programmed to handle, control will be returned to some point in B and
the stack will look as if C and D were never called.
To date two approaches have been put forward. The first (by Bob Campbell
and others) tries to implement exception handling as library procedures
containing some low-level code. If this scheme works (I don't think it
will) it will have the following advantages:
1- Requires no change to the language
2- Can be enabled and disabled over any size code block
and the following disadvantages:
1- Not integrated with 'compiler' raised exceptions
2- Has the runtime overhead of installing and de-installing handlers
3- Is very unsafe
The second (by Martin Odersky and others) extends the language. It was
printed in the November '85 issue of MODUS Quarterly. I have appended an
extract to the end of this article. This scheme has the following
advantages:
1- Safe
2- Integrated with 'compiler' raised exceptions
3- Almost no runtime overhead during normal operation
4- Simple to implement (similar to Exit in USCD Pascal)
and the following disadvantages:
1- Requires an extension to the language
2- Operates at procedure and module level
I would like to see both approaches the subject of further net discussion.
John Lancaster JANET: johnl@uk.ac.brunel.ee
Brunel University ARPA: johnl%ee.brunel.ac.uk@UCL-CS.ARPA
Uxbridge
England
UB8 3PH
Syntax and Semantics of Proposed Exception Handling Language Extension
Declaration of Exceptions
An exception declaration is similar to other declarations. There is a
special keyword (EXCEPTION) followed by a list of identifiers. Example
(taken from the module Files):
EXCEPTION
EndError, StatusError, UseError, DeviceError, DiskFull;
All the usual scope rules of Modula apply. Exception identifiers can be
exported and imported like normal Modula identifiers.
Raising Exceptions
Exceptions are raised when the program detects an error condition. (For
example, when the module Files has detected that the disk is full). Raising
an exception will transfer control to an exception handler, either provided
by the user or the system.
A program may raise an exception with the reserved word RAISE followed by
the exception identifier and optionally by a string. Example (taken from
MathLib):
IF x < 0.0 THEN
RAISE ArgumentError, 'Negative argument for Sqrt';
END;
When an exception is raised, the system looks in the current procedure for a
matching exception handler. If none is found, the calling procedure is
examined, then the caller of that procedure, and so on, until a matching
exception handler is found. This handler is then executed, and the
procedure containing the handler is exited. If no handler is found, the
system prints the exception identifier's name and the optional message
string.
Handling Exceptions
Exception handlers are written at the end of procedures and modules to
handle exceptions issued by a RAISE statement. The syntax is similar to the
familiar CASE statement. Example of a save procedure containing an
exception handler:
PROCEDURE SaveFile;
BEGIN
(*Code to write something to disk*)
EXCEPTION
| DiskFull :
Terminal.WriteString("Disk Full, Press <ESC>");
REPEAT Terminal.ReadChar (ch) UNTIL ch = CHR(27);
| DeviceError:
Terminal.WriteString("Bad Disk, Press <ESC>");
REPEAT Terminal.ReadChar (ch) UNTIL ch = CHR(27);
ENC SaveFile;
An exception handler may catch and then pass on an error condition with a
special form of the RAISE statement. This form is not followed by an
exception identifier or message string.
Technical Details
Message-ID:
<481@brueer.ee.brunel.ac.uk>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!seismo!mcvax!ukc!reading!onion!brueer!johnlShow Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!utzoo!mnetor!seismo!mcvax!ukc!reading!onion!brueer!johnl From: johnl@ee.brunel.ac.uk (John Lancaster) Newsgroups: comp.lang.modula2 Subject: Exception handling Message-ID: <481@brueer.ee.brunel.ac.uk> Date: Fri, 13-Mar-87 15:38:36 EST Article-I.D.: brueer.481 Posted: Fri Mar 13 15:38:36 1987 Date-Received: Thu, 19-Mar-87 05:09:31 EST Organization: Dept of EE & E, Brunel University, Uxbridge, U.K. Lines: 114 Keywords: exceptions, language extension, standard libraries, standardisation