Re: Exceptions (Was: OO2C problem)

["Mark K. Gardner" <mkgardne@rtsl3.cs.uiuc.edu>]

Thanks to all who have replied to my comments about exceptions. I am
especially grateful for the following pointer:

Dirk> You can add exceptions to Oberon2 -without the compiler even
Dirk> knowing about it- by using a combination of local (inner) 
Dirk> procedures and meta-programming. Please refer to the following
Dirk> Linz paper:
Dirk> ftp://ftp.ssw.uni-linz.ac.at/pub/Papers/Exceptions.ps.Z

I would recommend it to anyone interested in exceptions (in Oberon or
otherwise). It clearly explains different types of exception handling
semantics (terminate, resume or retry), as well as explaining three
different methods of implementation (setjump/longjump, compiler table,
stack walking via reflection [1]). I was aware of the first two
approaches, but not the last. The implementation which I proposed
(without compiler modification) is similar to both the first and last
categories, while the implementation I desired falls into the second.

The remainder of this message are my thoughts on "exceptions via
reflection".

An implementation of exceptions via reflection seems to fulfill most
of my wish list (except for more than one "exception scope"). Although
it avoids modification of the language, it does not avoid the
modification of the compiler. The Linz compiler, as an integral part
of the Oberon system, automatically has available to it a large amount
of symbolic information stored in the object file to enable dynamic
loading of modules. As far as I can tell, the ooc/oo2c compiler does
not maintain this information because it presupposes a more static
compilation model. Thus it is not clear how easy it would be to add
reflection to ooc/oo2c. Certainly it would require compiler
modification (even though it doesn't require language modification)
because symbols must be available for querying. Additionally, a
reflection library, which allows walking the stack, needs to be
written and walking the stack requires activation records. As Michael
pointed out a couple of messages ago, oo2c would have to be modified
because it does not implement nested procedures using activation
records.

Another problem in implementing exceptions via reflection as discussed
in the Linz paper is the issue of multiple local procedures with
signatures which match that required of the hander of an exception.
The paper does not discuss this but if an implementation chose one of
the multiple local procedures having the correct signature, two
systems implement exceptions via reflection they may not have the same
behavior. If it is an error to have ambiguous exception handlers,
either the compiler would need to be modified to find the error at
compile time, or the exception mechanism would need to find it at
runtime. I feel that the former is more in keeping with the spirit of
Oberon in that errors are made apparent as early as possible. However,
if the compiler needs modification, I would suggest that it is cleaner
to add exceptions to the language and make it explicit which exception
handler is to be executed rather than rely upon the exception
implementation to use the reflection mechanism to select a handler.

I know that this is purely an academic exercise because an
implementation of Oberon-2 with exceptions would not be Oberon-2, but
I appreciate the stimulation of the discussion. (I would still
appreciate comments on the use of variables which point to local
procedures restricted as outlined in my last message. Once again, it
wouldn't be Oberon-2, but it would be useful.)

Mark

-- 
Mark K. Gardner (mkgardne@cs.uiuc.edu)
University of Illinois at Urbana-Champaign
Real-Time Systems Laboratory
--