🚀 go-pugleaf

In article <5275@balrog.ctron.com> smith@ctron.com writes:
>In article <gsc.717334211@coombs>, gsc@coombs.anu.edu.au (Sean Case) writes:
>>smith@ctron.com (Larry Smith) writes:
>
>>>Someday, I hope to have time to add exceptions to Oberon
>
>>Whatever for?
>
>Because I consider them to be a fundamental control flow device, and
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>absolutely required to produce safe code.  I don't have time to enter
>into a full net.debate about it, so just take it as my humble opinion.
>I'll make just this one post.
>
>[interesting discussion of exceptions deleted]

Since exceptions have managed to sneak their way into ISO Modula-2, 
maybe this is a subject that should be discussed more, so people are 
clear why they are desirable or not desirable as a language feature.
I'll start with my two cents.

Above you refer to exceptions as a control flow device.  While control 
flow is the action that occurs, by definition, exceptions are supposed to 
be rare events, so most of the time control flow is not involved.
If exception handling is strictly a control flow device, then it is easy
to conclude (as Wirth and many others have) that they are not desirable,
since they 90% of the time they don't do anything for the programmer.  

There is another (perhaps more enlightening) way to look at exceptions, 
which is to consider them as _information_capturing_ devices, much like 
strong typing.  A list of exceptions raised by a procedure defines an
important piece of information about that procedure which would otherwise
not be explicitly stated.  For example consider the following two
procedure definitions, one without exceptions, one with.

WITHOUT EXCEPTIONS

	(************************************************************)
	(** Arbitrary precision integer division                   **)
        (** RETURNS result = a DIV b                               **)
        (**         NIL if b=0                                     **)
	(************************************************************)
        PROCEDURE Divide(a,b: T):T;

WITH EXCEPTIONS

	(************************************************************)
	(** Arbitrary precision integer division	           **)
        (** RETURNS result = a DIV b                               **)
        (** RAISES DivideByZero if b=0                             **)
	(************************************************************)
        PROCEDURE Divide(a,b: T):T RAISES {DivideByZero};

FROM A COMPILER'S POINT OF VIEW

        PROCEDURE Divide(a,b: T):T;
        PROCEDURE Divide(a,b: T):T RAISES {DivideByZero};

The second example captures more information about the Divide procedure.
This information can later be used by the compiler to enforce correct
usage of the procedure.  Hence the argument favoring exception handling
is very much identical to the argument in favor of strong typing.  

-- 
--Dennis Brueni (N0JSQ)        "The knack to flying lies in learning 
  brueni@csgrad.cs.vt.edu       how to throw yourself at the ground 
  <Project_Envision>            and miss."  -- Douglas Adams