Path: news.cs.au.dk!not-for-mail
From: "Jorgen Lindskov Knudsen" <jlk@cs.au.dk>
Newsgroups: comp.lang.beta
Subject: Re: exceptions: (atle // confused (# again #) atle)
Date: Mon, 19 Jun 2000 22:33:28 +0200
Organization: University of Aarhus, Department of Computer Science (DAIMI)
Lines: 53
Message-ID: <8im02p$8s5j$1@xinwen.cs.au.dk>
References: <20000619173848.8485.qmail@noatun.mjolner.dk>
NNTP-Posting-Host: isdn-002.cs.au.dk
X-Trace: xinwen.cs.au.dk 961446809 290995 255.255.255.255 (19 Jun 2000 20:33:29 GMT)
X-Complaints-To: news@cs.au.dk
NNTP-Posting-Date: 19 Jun 2000 20:33:29 GMT
X-Newsreader: Microsoft Outlook Express 4.72.3155.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Xref: news.cs.au.dk comp.lang.beta:12447

There have today been quite some discussion on the issue of exception
handling in BETA, including some stating that BETA does not have exceptions
:-)

Just because the BETA exception model is not identical to the C++/Java
exception handling model, does not imply that there is none :-)

Simply stated, there are three different models of exception handling (there
are more, but I refrain from making this into a complete reference into the
history of exceptions :-).

The first model is 'state checking':  This is the model used by e.g. C.
Exceptions are signelled form a routine by setting a return value of the
routine.  By convention, negative values indicate that an error have
occurred, and the negative number is a specification of the type of error.

The second model is 'dynamic exception handling': This is the model used by
e.g. C++ and Java.  Here exceptions are raised by a routine by socalled
'raising an exception'.  The consequence of raising an exceptions is, that
the runtime system have to find a handler for this specific type of
exception.  In dynamic exception handling, this handler is found by the
runtime system by traversing the runtime stack backwards from the place of
the raising of the exception.  During traversal, handlers are investigated
(usually located in socalled try-blocks) to see, if they match the raised
exception, and if so, the handler is executed, whereafter either the program
is resumed from the point of raising the exception, or the part of the stack
between the raising point, and the try-block is terminated, making the
program continue after the try-block.  The exact behaviour is dependent on
the language, and possibly also the user-code.

The third model is 'static exception handling': This is the model used in
BETA.  Raising exception is similar to the dymnamic model.  The difference
is, that is is _not_ the runtime system, that makes a traversal of the
runtime stack to find some appropriate exception handler.  However, the
static definition of the exception implied the definition of the handler,
being associated with the exception, implying that the handler is statically
specified in the program text.  The virtual mechanism of the language is
used to make it possible to associate different handlers to an exception.

Which of these model, one prefer is partly a matter of taste, and background
(we all tend to like the most, what we have been used to use in other
settings).  The BETA libraries use the static model exclusively, but nothing
prevents users for implementing the 'state checking' model in their own
systems.  However, dynamic exception handling in presently not available in
the language (nor the system).

I hope this makes the discussion clearer.

Regards,
Jørgen Lindskov Knudsen