# Exceptions proposal **URL:** \ **Category:** Language enhancement\ **Created:** [February 9, 2023, 9:07pm UTC](https://fortran-lang.discourse.group/t/exceptions-proposal/5160 "2023-02-09T21:07:00Z")\ **Posts on this page:** 1\ **Showing post:** 8
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [February 10, 2023, 8:57pm UTC](https://fortran-lang.discourse.group/t/exceptions-proposal/5160/8 "2023-02-10T20:57:16Z")
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). --- _[View the full topic](https://fortran-lang.discourse.group/t/exceptions-proposal/5160)._