Re: Exceptions

[Keith Hopper]

Hi,
     Before anyone reads any further may I state that one of the most
important things about a language is to make it consistent.   A couple of
years ago when we were first addressing the ICSI 1.2 Sather run-time
facilities we reasoned that whatever disturbance to the flow of control of
a program may be that it has three facets - a subject (object doing the
raising, an object - the state of which leads to the raising and the agent
(thread) which performed the raising action.  My previous message was all
about that scenario.

     Nobbi disagrees - as follows.  I hope no-one will take offence at my
fairly blunt comments - no offence is intended!
 
> "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! 

     Rubbish! Of course there can -- what about a divide by zero - it
certainly doesn't occur in the program - it is provided by the OS.  What
about a shared object in a distributed program - there are certainly at
least two threads involved - one might be thought of as the owner and take
up the cudgels when an exception is raised - and so on!!!!!

> "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.

     No!!!! And again NOOOOOOOOOOO!

    The reason relates to a behaviour NOT to an object - and the Required
Library you will find does raise exceptions on objects other than self -
indeed that would be the norm in a program too.  The reason has nothing to
do with the object which is the 'subject' of the exception - it has to do
with a behaviour specified for the object which is raising the exception -
the raising agent if you will.

> "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.

     This is the 'object' of the exception - the state of which gave
occasion to the raising be code providing the behaviour of the 'subject'.

> OK, interrupts, and asynchronous events in general, have nothing in
> common with exceptions. 

     Eeeeeeeeeeek!  They are identical in nature - absolutely identical --
there is no logical difference between them at all!

> ------

> 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.

     Java, I am sorry to say is brain-dead in this area.  As I have tried
to explain twice now ther is a subject of an exception which is the object
the behaviour of which caused the exception to be raised and there is the
object of the expression - the state of which gave rise to the exception in
the first place - and the thread which raised the exception which - as you
say - is frequently - but NOT NECESSARILY the thread to handle the
exception.

> ------

> Finally, a little remark: the quit of an iterator is something very 
> different from raising an exception. 

     Grrrrrrrrrrrr!  No it isn't - it isn't at all different. What is
different is the action taken as a result - in the case of a quit statement
the action is benign - in the case of the exception the action may be, as
you say, last ditch!

     Sorry to disagree so seriously but I have the sneaky feeling that your
discussioin revolves around a present implementation - not the
implementation which should be

-- 
City Desk
Waikato University
[PGP key available if desired]