From rotth@gmdzi.gmd.de Tue Aug  2 15:58:19 1994
Received: from gmdzi.gmd.de by dkuug.dk with SMTP id AA13619
  (5.65c8/IDA-1.4.4j for <SC22WG5@dkuug.dk>); Tue, 2 Aug 1994 13:58:33 +0200
Received: from [129.26.14.57] by gmdzi.gmd.de with SMTP id AA23986
  (5.65c8/IDA-1.4.4 for <SC22WG5@dkuug.dk>); Tue, 2 Aug 1994 13:58:19 +0200
Date: Tue, 2 Aug 1994 13:58:19 +0200
Message-Id: <199408021158.AA23986@gmdzi.gmd.de>
To: SC22WG5@dkuug.dk
From: Karl-Heinz.Rotthaeuser@gmd.de
Subject: Exception Handling Proposal (Ref. N974)
X-Charset: ASCII
X-Char-Esc: 29

From: DIN Working Group Fortran

Subject: Exception Handling Proposal (Ref. N974)


The exception handling proposal by John Reid (ISO/IEC 
JTC1/SC22/WG5-N974) is a very good basis for a general 
Fortran90 exception mechanism. We think, however, that general 
problems still remain to be solved:

1.      Precision of the "point of error"

We could not find any clear way to limit the imprecision of 
error detection within ENABLE blocks: the CHECK statement or 
the IMMEDIATE specification (which is defined via the CHECK 
statement) do not really help. Consider e.g. the following 
program example:

ENABLE (OVERFLOW)
        A1      =       B1*C1
        A2      =       B2*C2
        .
        .
        .
        A10     =       B10*C10
HANDLE
...
END ENABLE

Since all these statements do not have data dependencies, a 
processor may well reverse the order of evaluation, i.e. 
compile

ENABLE (OVERFLOW)
        A10     =       B10*C10
        .
        .
        .
        A1      =       B1*C1
HANDLE
...
END ENABLE

Now let's assume that a

CHECK (OVERFLOW)

statement is inserted after each assignment (either directly or 
indirectly via an IMMEDIATE specification). Does it really make 
any difference? Would a processor be allowed to compile:

ENABLE (OVERFLOW)
        TEMP10  =       B10*C10
        TEMP9   =       B9*C9
        .
        .       
        TEMP1   =       B1*C1

        A1      =       TEMP1
        CHECK   (OVERFLOW)
        A2      =       TEMP2
        CHECK   (OVERFLOW)
        .
        .
        .
        A10     =       TEMP10
        CHECK   (OVERFLOW)

HANDLE
...
END ENABLE

If this processing is standard conforming (and we could not find 
any wording preventing this) then the CHECK statements do not 
really increase the precision of error detection.
To solve this problem, we think that it is necessary


-       to specify exactly for each intrinsic operation which 
        exceptions are signaled in which circumstances, and

-       to specify that at each CHECK statement the state of all 
        signals must correspond to the above definition.

2.      Global name space for exceptions

If the global scope of exception names should really be a 
problem (We don't think it is), then we would prefer the 
following (simple) solution:

-       disallow user signal names and limit the exception names 
        to intrinsic ones (such as ALLOCATION_ERROR),

-       add USER_SIGNAL (i.e. "unspecified signal caused only by 
        the SIGNAL-statement") to the set of intrinsic exceptions,
        and

-       add an optional parameter ERROR_INFORMATION to the SIGNAL 
        statement and add some corresponding inquiry functionality for 
        this error information to allow the transport of some 
        unspecified additional error information from the signal 
        raising code to the signal handling code.

3.      Exceptions in handler blocks

What happens if exceptions occur during the execution of a 
handler block? Do they cause a branch to the beginning of the 
handler block (since the handler is part of the ENABLE 
construct controlled by the handler)? When do such exceptions 
cause a branch? (If they do not cause any branch until the end 
of the handler block: are the signals set quiet at this 
point?).
We think some further specifications are needed.



4.      Intrinsic error conditions

4.1)  New SYSTEM_ERROR condition:
        We think it's too restrictive to say that only the 
        intrinsic exceptions (such as ALLOCATION_ERROR ...) may be 
        raised by the processor (i.e. without explicit SIGNAL 
        statements).
        Instead, some new intrinsic exception type, e.g. 
        SYSTEM_ERROR, should be defined which may be raised any 
        time under conditions which are processor-defined (this 
        could allow to write portable code to handle such 
        processor-dependent conditions by e.g. properly closing a 
        large complex application).

4.2)  ALLOCATION_ERROR/INSUFFICIENT_STORAGE:
        We don't think that it is useful to distinguish between 
        these two kinds of exceptions.

4.3)  UNDEFINED:
        This condition should be dropped since it is defined too 
        vaguely to allow anybody to write portable code by using 
        this exception.
        (The detection of undefined variables, furthermore, is 
        also rather a debugging feature which should remain out 
        of the scope of a language standard).

4.4   INEXACT/INVALID:
        This condition refers to general capabilities of the 
        processor rather than events corresponding to some 
        particular piece of a program; therefore, we would prefer 
        to drop these conditions and offer some inquiry function 
        for processor properties instead.

4.5.) GENERIC (mentioned as part of DEFAULT):
        What is this condition class? Does it refer to "all user-
        defined signals caused by the SIGNAL statement"?


Karl-Heinz Rotthaeuser
---------------------------------------------------------------
Karl-Heinz Rotthaeuser, e-mail: rotthaeuser@gmd.de
Phone: +49-2241/14-3228, Fax: +49-2241/14-3003,-3006
National Research Center for Computer Science (GMD)
Rathausallee 10, P.O.Box 1316, D-53731 Sankt Augustin, Germany