Exceptions proposal

Language enhancement
8

TL;DR: Start small with exception handling in Fortran 202Y will be my recommendation.

For whatever it’s worth, I do not at all like the working approach in this paper by @vsnyder :

  1. It immediately jumps into a “solution mode” with very little to poor treatment of the desired use cases,
  2. Besides, the solution approach laid down in the paper appears rather outdated. A lot of “water” has flown since the paper was first put together and slapping a recent date on it does not make it any current or relevant for future.
  3. A lot of effort has gone into the standard with IEEE floating-point exceptions that at least for now, floating-point exceptions need not be covered in the above-mentioned use cases, at least during first revision of exception handling in the standard,
  4. That is, any initial treatment of exception handling in Fortran 202Y (hopefully this is the revision that will introduce something; if not, then Fortran 203X) should study all the use cases closely and consider working toward a few simpler cases only based on guidance from compiler implementations re: run-time cost and also the possibilities of prototyping such as with LFortran based on feedback from @certik and team.

In terms of use cases, my suggestion(s)

  1. for the first case is when an ERROR STOP statement instruction takes place in a library method that initiates “error termination” by a Fortran processor. Here the use case will be for the caller to be able to supply a “handler” method, perhaps with certain defined interfaces (a la defined IO), and which then gets executed with some defined semantics during the error termination. The caller can then complete needed actions in this handler. A loose analogy might be the FINAL procedure with finalizable types.
  2. a companion to case 1 i.e., when a Fortran subprogram is invoked by a processor other than a Fortran main program, then to extend the handler scheme toward some procedure interoperable with a C companion processor.

As far as I am concerned, if Fortran 202Y can cover just these 2 use cases, it will more than satisfy the 80-20 rule (Pareto principle) with the needs we have noticed in industry with Fortran codes (primarily libraries aka DLLs).