Better error handling

[certik]

A common request is to improve how error handling is done.

Whether exceptions, or some other mechanism.

[zbeekman]

I often roll-my-own error stack, which is a pain, but let's you pass it in to elemental and pure procedures. It would be nice to have at least a pre-defined object with similar capabilities---something that can carry around state and provenance of errors so that computationally intensive code regions can remain pure/elemental etc. and don't need to interact or abort on errors, but can pass back meta data about when and where an error occurred.

Also, the try...except syntax convention of other languages feels natural and appeals to me.

[milancurcic]

Relevant: https://j3-fortran.org/doc/year/19/19-224.pdf

I am not convinced that the proposed solution is a step in the right direction. Specifically:

Detection of all exceptions that are identified by enumerators of the type EXCEPTION defined in the intrinsic module ISO_FORTRAN_ENV, is always enabled.

This approach necessarily implies that every statement runs (internally) in an if/then/goto block, a common criticism of try/except in Python, for example. There are many applications (most HPC software) in which exception handling would be preferred to be disabled by the user in production.

Further, the example (Section 6) seems to me as verbose as if it was handled with C-style exception handling, but with new syntax for the programmer to learn.

[certik]

@milancurcic yes, the most common objection from the committee is that exception handling like that can easily cause missed optimization opportunities, and thus any proposal that could be put forward should not hamper performance.

The syntax issue you mention is also a problem. Another issue is what kind of exceptions should be handled, and whether floating point exceptions fall in that category.