Re: Exceptions (Was: OO2C problem)

[Dirk Muysers <dmuysers@capgemini.fr>]

You can add exceptions to Oberon2  -without the compiler even knowing about it-
by using a combination of local (inner) procedures and meta-programming.
Please refer to the following Linz paper:

ftp://ftp.ssw.uni-linz.ac.at/pub/Papers/Exceptions.ps.Z

Regards.
/dm

-----Original Message-----
From: Ian Rae <ianrae@istar.ca>
To: ooc-list@informatik.uni-kl.de <ooc-list@informatik.uni-kl.de>
Date: Sunday, March 15, 1998 3:43 PM
Subject: Re: Exceptions (Was: OO2C problem)


>> From: Mark K. Gardner <mkgardne@rtsl3.cs.uiuc.edu>
>> *** Now for the controversy ***
>>...
>> Realizing that Oberon-2 is nearly perfect and therefore being
>> reluctance to change it, I attempted to allow the following:
>> 
>>     ...
>>     TRY(handler1);
>>       ...
>>     CATCH();
>>     ...
>>     TRY(handler2);
>>       ...
>>     CATCH();
>>   END p;
>> 
>> which works (in that it doesn't crash) as long as you do not access
>> any local state. Not quite as nice, but it doesn't require a change to
>> the language or compilers... or so I thought. As was pointed out, the
>> language definition prohibits this. So much for no changes to the
>> language! (Note that it is also not fool-proof in that it would be
>> easy to forget a "catch()" because the compiler is not required by the
>> language definition to look for a close to the exception scope.)
>> 
>> One approach is to use the existing Exception.Mod to add a global
>> procedure as a handler at the location of the TRY and to remove it at
>> the location of the CATCH. One drawback is that the global handler is
>> separated from the code containing the exception block and hence
>> requires more effort on the part of the programmer to keep both the
>> handler and the code in mind. Some may suggest that having the
>> exception handler away from the code in the exception scope is an
>> improvement. I could be convinced if it weren't for the next drawback.
>> I firmly believe that allowing access to local state is very important
>> if exceptions are to be more than a way to print an error message and
>> die. It is especially important if recovery is attempted. Even if I am
>> only going to print an error message and die, having access to the
>> local state allows me to be more specific about why the procedure is
>> dying.
>
>I'm not a big fan of exceptions but it's interesting to see how they can be
>added to Oberon.  Having access to locate state is not that important if
>exceptions are used only for truly exceptional situations where control 
>is passed to an outermost level of the program.  The exception object 
>itself can include any relevant local info.
>
>--Ian