Re: Exceptions

[Norbert Nemec]

On Sat, Oct 14, 2000 at 09:55:56AM +1300, Keith Hopper wrote:
> In article <address@hidden>,
>    Norbert Nemec <address@hidden> wrote:
> 
> > Is that really a fundamental language problem? Doesn't it rather depend 
> > on the EXCEPTION class that still has to be constructed? Just let it 
> > take a self: $OB as arguent to create and store it. As for the feature 
> > it was raised for: Sather does not know any concept of handling 
> > methods, features or classes at runtime. 
> 
>      In a nut-shell - YES!
> 
>      Let me try and explain why this involves the language....

Sorry, but after reading this long mail of yours I come to the 
understanding that we are talking about completely different things. 

Let me try to explain from the ground up:

You wrap up a piece of code in a 'protect' block:

    protect
        ... some production code ...
    when EXC_CLASS then
        ... handler code 1 ...
    else
        ... Help!!! ...
    end;
    
Usually, only the production code runs through and everything is fine. 
Now what you are worrying about is where to get those three pieces of 
information "thread", "reason", "object" from. Simple explanation:

"thread": The exception was definitely raised within the same thread 
you are still in! There is no handling of exceptions between threads. 
There can't ever be! As soon as an exception is raised anywhere, the 
stack is rolled back until the closest matching protect statement is 
found. In a thread, the stack is created with the fork statement. You 
can't roll out of that. If the exception was not catched before the 
thread "leaves" the fork, only way to handle this is an asynchronous 
event, i.e. an interrupt or a fatal error.

"reason": This is simply encoded in the object that is used as 
exception type. Every exception must have started at some "raise" 
statement in the code. As long as you do not raise two identical 
objects in two different raise statements, you can clearly define which 
statement in which method is was. Of course with the strange "raise self" 
statements that are used in the Sather-W library, that information is 
thrown away, because the "exception" variable does refer to the same object
no matter which method it was called on.

"object": I do not know whether this is generally necessary, but where 
in cases where it is needed, it is very simple to achive. Just pass a 
reference to "self" to the exception creation in the raise statement.

------

Now for the "external" disturbances in the flow of control. To me it 
sounds like you are talking of interrupts etc. If not, please correct 
me.

OK, interrupts, and asynchronous events in general, have nothing in
common with exceptions. Just imagine this: It is very common to have an 
interrupt handler that does something and afterwards resumes at the 
point where the flow of control was interrupted. This is not possible 
from an exception handler. Once the exception handler is called, the 
stack has already been unrolled and all the local data and other 
information about the exact state is lost.

------

And for your solution with the "err" specification for methods: I see 
no difference at all to the solution of specifying the exceptions 
raised by a method. Just as it is done in Java. Just as it has been 
discussed for at least two years now for Sather.

------

Finally, a little remark: the quit of an iterator is something very 
different from raising an exception. They may act similary in that they 
quit the current method and also quit the block the method was in, but: 
The quit is a very well defined part of the iterator concept that 
mainly consists of saving the state of the iterator and resume there at 
the next call. It just saves a special state that the loop handles by 
quitting.

The "raise" on the other hand causes a "panic" reaction: Drop anything 
you have and run to the next place of safety. If there is anything that 
has to be done in a controlled way while the execution "jumps" out of 
methods, the exception has to be caught and then raised again. For 
example, checking postconditions in this case would mean implicitely 
having a "protect" for every method. You may consider this a 
"implementation" detail, but it helps very much in understanding the 
concept to really imagine it as a long jump to closest protect block.

Those two are used for absolutely different purposes and trying to 
artificially unite the concepts will net help at all in writing clean 
programs.

Ciao,
Nobbi

-- 
-- ______________________________________________________
-- JESUS CHRIST IS LORD!
--          To Him, even that machine here has to obey...
--
-- _________________________________Norbert "Nobbi" Nemec
-- Hindenburgstr. 44  ...  D-91054 Erlangen  ...  Germany
-- eMail: <address@hidden>   Tel: +49-(0)-9131-204180