[J3] Exception handling - Golang proposal

[Robert Corbett]

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

> On Jul 7, 2019, at 9:34 AM, Bill Long via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> I’m not convinced that there was sufficient enthusiasm for exception handling at the Berkeley meeting.  Especially compared to some form of generic programming.  Some things to consider:
> 
> 1) Fortran already has a large set of status and error message specifiers for statements, and status and error message arguments for intrinsic procedures, as well as a core part of the IEEE modules dedicated to error handling.  Any proposal for exception handling needs to convince us that is does something needed by (good) programmers, that is not redundant with already existing facilities, and does not harm code optimization and performance. 
> 
> 2) We started wth a goal for F202x being a relatively small revision, after three consecutive large revisions.  Trying to do both generics and exception handling in F202X will negate that stated goal.  Vendor fatigue is not insignificant.  We should consider a straw vote at the meeting next month along the lines of:
> 
> T202X should include 
> 
> A) Generics/templates, but not exception handling,
> 
> B) Exception handling, but not generics/templates,
> 
> C) Both generics/templates and exception handling, and reject the idea of F202X being a small revision, or
> 
> D) Undecided. 
> 
> Cheers,
> Bill
> 
> 
>> On Jul 6, 2019, at 7:52 PM, Steve Lionel via J3 <j3 at mailman.j3-fortran.org> wrote:
>> 
>> One of the major features we've said we'd like to see in F202X is "exception handling", but this is probably the least well defined (for Fortran) of any of the features proposed. Tonight I ran across a proposal being suggested for the Go language which bears some similarities to at least one proposal I've seen for Fortran. Some in the Go community don't like it.
>> 
>> I haven't studied it enough to see if there are any "take-aways" for Fortran, but I found it worthwhile reading as I saw echoes of some of our earlier discussions.
>> 
>> The actual proposal and discussion: https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md
>> 
>> Some other discussion: https://github.com/golang/go/issues/32437
>> 
>> Article about the "kerfluffle": https://thenewstack.io/this-week-in-programming-do-or-not-do-there-is-no-try/
>> 
>> Steve
>> 
> 
> Bill Long                                                                       longb at cray.com
> Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
> Bioinformatics Software Development                      fax:  651-605-9143
> Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425
> 
>