Re: Exceptions

[Keith Hopper]

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.  There are two
fundamental sources of 'Disturbances in the flow of control' - the
environment in which the program is executing - and the program itself.

     At present the first kind just happen and, if the operating system is
involved the program may be permitted to handle some of them - but this is
not done in the same way the internal 'disturbances' are handled.  Whether
'caught' or not the program knows a 'reason' and thread - but not object.

     The second kind (internal program generated 'disturbances') provide a
thread and an object - but no reason.

     One of the principal reasons for our continuing work on a new run-time
engine is to unify the presentation of both forms of 'disturbance' -
internal AND external!  This can be done by making the lowest level of the
run-time engine an event registration and handling mechanism.  This works
fine!

     In order to enable a Sather program to take full advantage of this
there needs to be a way in which the writer of a program can access these
three components - object, reason and thread.

     The suggestion of an abstract class $EXCEPTION only attempts to move
the mechanism outside the language - besides introducing the dreaded $OB
around which I quake in expectation of disaster!.  Remember that one cannot
'magically' provide handles to objects which are in the run-time engine
without the compiler being able to generate appropriate code to do so.

     The concept of a thread is native to the language - bearing no
essential relationship to the identity of the thread - which is just a
handle and might as well be the library class THREADID - which I want to
rename to just THREAD < $REFERENCE if I get the chance!

     The concept of an object is, of course, the object of the language (if
you will pardon the pun).

     This leaves reason!  Without wishing to bore you with a very long and
detailed discussion of semantics which occurred a few years ago in the
ISO/IEC Modula-2 standards working group - we cannot sensibly provide such
a thing without knowing the external reasons (internal ones can be handled
by the compiler).  If these are to be handled uniformly then the only
sensible way would be to provide an EXTERNAL class (more on this later) and
a mechanism for specifying reasons - IN THE LANGUAGE.

     Again asking forgiveness for the pun, the reason that this (the
reason) has to be handled in the language is that it is fundamentally
attached to a method - in fact the reason is an inability of that method to
handle some situation.

     Let me sum up so far -

     (1)  The object involved is given the identity 'exception' by
     the language.

     (2)  The processor involved is given by a thread (REFERENCE).

     (3)  The reason involved is given by identifying the method in the
     class raising the exception.

     All of these are part of the language.   You might say that one method
name may be overloaded - so which one is involved?  You might say that any
method can raise more than one exception - so which one is it?

     The way in which these two question may be answered is the fundamental
point here - this is why the language needs a way for the programmer to
arrange unique identities for these reasons.  Now just think abour this a
little bit longer - when an exception is raised it is by no means certain
what the class of the object involved will be - it is quite possible for
the actual object to have an abstract type.  The raising of an exception
cannot therefore associate the reason with the object - but with the
behaviour (method) of some object of the raising class.

     Just think about handling this.  The handler is specified for a
particular object class - not for the class in which the problem occurred -
which provides the reason only - so that reason really has to refer to the
object in which the situation was detected - and the method involved.  This
could easily enable double dispatching - or, if we had some way of
specifying which method was in use then even triple dispatching is
possible.

     ... which all brings us nicely back to the way in which a reason
could/should be specified when writing a program source text.  Nobbi states
that "Sather does not know any concept of handling methods, features,
classes at run-time."  I am sorry to say that it does!  Well it can
certainly handle classes in things like typecase statements.  It can
certainly handle threads at run-time - AND it definitely handles methods at
run-time when dispatching on over-loaded routines using abstract classes. 
At present the programmer can't explicitly handle the last one - which is
why there needs to be a minor change in the -language- to permit this.

     May I suggest the following -

     Add to the features of a class (including an abstract class) signature
a new (optional) keyword 'errs' which may be followed by a list of error
names.

     This would mean that a signature would look like -

          doit(
                 arg1 : CARD,
                 arg2 :WIDGET
                 ) : FRED

           pre ...

          post ...

          errs doit_overflow, doit_underflow ;

     When implementing this signature the same errs clause is needed. 
There then needs to be a built-in value name 'reason' which is accessible
within an exception handling clause.

     The need for this to be part of the language can now be seen since the
compiler needs to ensure that at run-time all of the reasons are unique
across a whole program - not restricted to a single class or method.  If
the reaon names are given in an abstract signature then the handling clause
may need to be able to differentiate on the actual class/object raising the
exception - hence the need for a second additional built-in value name, say
'source'.

     Note particuarly that 'reason' and 'source' are NOT keywords but
values!!  The only additional keyword is 'errs'.  This, incidentally,
encapsultes the idea of what goes on when an iter cannot proceed - at
present the language has a hidden 'errs' clause for every iter which may be
thought of as having a siqnature something like

          elt! :THING

          pre ...

          post ...

          errs iter_quit ;

where the 'handler' for the iter_quit reason just acts like a quit
statement.  This has a nice ring to it - don't you agree?  It is a form of
unification of existing concepts - not really changing the language in its
essentials.

     One final topic, this class EXTERNAL which I mentioned above. This
needs to specify signatures for those actions in the environment which
cause 'disturbances'.  It is a way for the programmer to handle these
things correctly - it just contains skeleton signatures corresponding to
external actions - say something like

     class EXTERNAL is

     div() errs divide_by_zero, divide_underflow ;

     add()  errs add_overflow ;

     minus() errs minus_overflow ;

     address() memory_error ;

     etc, etc, etc

in which the 'routines' are, of cousre, dummy - but serve to show the
programmer reading the source text the activity going on when an exception
with the inidcated reason was raised.

     There may be merit in having two classes of this kind in the Required
Library - say EXTERNAL_SYS and EXTERNAL_OS - the former for exception
occurring in the run-time engine (as the examples above) and the latter for
errors specific to a particular operating system.

     Sorry this is so long, but if there is going to be a minor change then
it merits serious discussion.

                kh

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