[J3] [EXTERNAL] Re: Exception handling - Golang proposal

[Van Snyder]

On Sun, 2019-07-07 at 11:37 -0700, Robert Corbett via J3 wrote:

> I thought there was support for adding exception handling at the
> Berkeley meeting.
> 
> I am not enthusiastic about adding exception handling, because I fear
> that we will get it wrong and produce a mechanism that will make many
> optimizations impossible.  Exception handling in C++ blocks many
> possible optimizations.  The paper by Herb Sutter gives examples where
> this occurs.  Of course, he is arguing for an alternate mechanism, and
> so he might be biased.  I could support addition of exception handling
> that does not seriously degrade performance.
> 
> I read a few papers on "zero cost" exception handling.  "Zero cost"
> means different things to different authors.  A paper on C++ exception
> handling claimed to describe an implementation that has zero cost
> unless an exception occurs.  However, the mechanism described assumed
> there would be no inter-statement optimizations in regions where
> exceptions could occur.
> 
> Herb Sutter described a "zero cost" implementation that could be
> implemented using a generalization of alternate returns (functions
> would have to support alternate returns) and switching on error codes.
> The proposed implementation costs about what it would cost to
> implement error handling manually using alternate returns and
> switching on error codes (which is not zero).  The cost depends on the
> computer architecture and the calling conventions used.
> 
> Any proposal for exception handling should include a description of
> how it might be implemented.  I would like an implementation to exist
> before a proposal is added to the standard, but I know that is
> unlikely.
> 
> Bob Corbett


I don't think decisions about existence or design of Fortran features
should be based upon imagined and superficial similarity to features
with superficially similar names in C++.  We are not required to design
our system to be exactly the same as the C++ system.  Other languages
with different requirements, from which we can draw inspiration (and
caution), do exist.

I have proposed an exception system, described in 18-115.  An explicit
decision was made not to discuss it, before meeting 215.  Did anybody
read it?  Our schedule for this project, if we decide to have such a
project, would be one year ahead of where it is now if we had not
ignored it.  John Reid proposed a system several decades ago.  It would
be more fruitful to discuss an existing proposal, explicitly designed to
fit within the four corners of Fortran, rather than to speculate about
some imaginary proposal about which there is apparently some concern
that it would include all the defects of the C++ system.

The requirement to detect and report exceptional conditions could impose
a performance penalty, or could greatly improve performance, depending
upon whether the exceptional condition is detected by hardware.  The
LACK OF block structured exception handling imposes serious performance
penalties upon, for example, a procedure that attempts to compute the L2
norm of a vector, without undue overflow or underflow unless the final
result would overflow or underflow.  There is an example in section 6 of
18-115.  In Fortran, the only way to detect overflow or underflow is by
using IEEE features.  This requires explicitly testing conditions after
every arithmetic operation.  The performance penalty is obvious:
Hardware detects the exception; the runtime library's exception handler
sets a flag; the user's program explicitly inquires the value of the
flag, which has a cost even when the exceptional condition does not
occur.  The structure penalty is also obvious if there is more than one
place where an exceptional condition might occur.  The exception handler
would either appear after every checked operation, or be put into an
internal procedure (except if it occurs within an internal procedure),
or be accessed by a GO TO statement.  If it's not accessed by a GO TO
statement, a nest of IF constructs, as deep as the number of places
where exceptional conditions are checked, might be necessary.  If this
spans the boundary of a DO construct, a messier pile of worms escapes
from the can.

Detecting violation of subscript bounds requires testing before every
array element or section reference (except for references to rank-1
dummy arguments in Univac FTN on 1100/40 and later, which were checked
by hardware).  This imposes a performance penalty.  It is precisely for
this reason that subclause 10G of the Steelman document
(https://en.wikisource.org/wiki/Steelman_language_requirements#10._Exception_Handling) required that it be possible to suppress detection of specified exceptional conditions, and that subclause 11.6 of the Ada Reference Manual (https://www.adaic.org/resources/add_content/standards/05rm/html/RM-11-6.html) explicitly addresses the issue of the relationship between exceptions and optimization.  It is also for this reason that 18-115 specified the enumeration type OPTIONAL_EXCEPTION and a list of enumerators of that type.

Alternative to disabling detection of specific exceptions, 18-115
proposes that detecting optional exceptions must be explicitly enabled.
Subclauses 3.2 and 4.4 of 18-115 might need some attention in this
respect.  Subclause 3.2 specified that detection of all conditions
identified by enumerators of the enumeration type EXCEPTION is always
enabled.  Detecting exceptions identified by enumerators of the
enumeration type OPTIONAL_EXCEPTION, an extension of type EXCEPTION, for
example, detecting subscript bounds violations, must be explicitly
enabled.  Suppressing detection of specific exceptions could be
specified by command-line options.  Edsgar Dijkstra likened this to
flight attendants requiring you to buckle your seat belt before the
airplaine is pushed out from the terminal.  You taxi around on the
airport apron with you seat belt attached.  Then, just before take-off,
staff come around and take away your seat belt.

Exceptions that are generated by hardware (e.g., floating-point
overflow), or by the runtime library (e.g., incorrect character in a
numeric input), should not cause any runtime overhead until they occur
-- unless we do something boneheadedly stupid, like pretending that
execution can resume in the middle of an expression or block or I/O
statement or... after "correcting" the problem.  When an exception is
raised, execution of the statement and block in which it occurred should
be terminated, and control transferred to the most-closely contained
exception handler, if there is one within the failing procedure, or
execution of the procedure is terminated followed by raising the
exception in the invoking procedure at the point where the failed
procedure was invoked.

As Bob points out, one method to implement exception propagation is to
use alternate returns.  Fortran has had this method since 1966.  Unlike
the "opportunity" to check a status variable, one cannot ignore an
exception that is raised and propagated by this method.  One might not
handle it, but if the referenced procedure has explicit interface and an
alternate return specifier does not correspond to an asterisk dummy
argument, the program unit (hopefully) will not compile.  If we do not
provide block-structured exception handling, alternate returns need to
be restored to first-class status, and their descriptions printed in a
full-size font.  Whether a dummy argument is an asterisk should
participate in generic resolution (15.4.3.4.5p3).  ERR=<label> should be
added to all statements that have STAT=.  Alternate returns can handle
only user-detected and user-propagated exceptions.  They offer no help
for efficient handling of hardware-detected exceptions, such as
floating-point overflow.  For efficient detection and handling of
hardware-detected exceptions, there is no obvious efficient alternative
to block-structured exception handling.

Bob was concerned that we might botch the design of an exception system.
For that reason, it might be wise to pursue it as a TS with an
independent development schedule.  The foreword might promise that it
will be included in a future standard as specified in the TS unless
serious technical problems are encountered.  Or it might explicitly not
promise that it will be included.  This would allow processors to
implement it with some confidence that it would appear in the standard
as described in the TS -- unless serious unavoidable implementation
problems are discovered.  If so, a revised TS can be produced.  This is
better than waiting and hoping for helter-skelter speculative
development of incompatible systems within different processors.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20190707/273bd648/attachment-0001.html>