Handling and propagating errors in stdlib

[aradi]

Before the file system layer (see #201, #220) in stdlib can be implemented, it would be important to reach some agreement on how to signalize errors within stdlib. I am not talking about logging, as this is an add on we can discuss later. I want to concentrate here on how errors can be passed between routines in stdlib.

Fortran's current approach to report status in I/O commands is to have some optional integer argument, returning the status of the operation. If the argument has not been specified, the code stops in case of errors. I'd propose to generalize this principle, but using derived types to achieve higher robustness and flexibility:

• The status should become a derived type (type(status)), which methods allowing to set and query it.
• The status-type has a finalizer. If it goes out of scope with an unhandled error in it (without having been handled by the caller), it calls error stop.
• The derived has a special field which contains a class(error) item. It can carry arbitrary types derived from a base class, so that arbitrary complex error information can be passed around. This way, the error signaling mechanism is extensible, we could even think to add an error-hierarchy as we have in Python.

I have made a toy project to demonstrate the principle. Please, have a look at it and let me know what you think.

A few more notes:

• This error passing should be applied to cases, where error reporting via special values in not feasible (e.g. change_dir()).
• We could of course implement in the error-class to information about how it was propagate (backtrace).

This issue is related to several other error discussons, e.g. #219 , #193, #95. My suggestion is, again, to first reach agreement on the low-level of the error reporting, and we can add extended functionality, such as logging, on top later.

[certik]

Would the idea still be that if the status argument is not provided, that it will error out right away? I think this is the key principle.

I think your approach can work.

The only possible downside that I can see is that you can notice that built-in Fortran functions never return a derived type, but only simple arguments such as integers or arrays. The reason for that is that it does not impose any particular derived type on the user. In here, we would be imposing the type type(status). So that's the main downside compared to returning just an integer.

Regarding speed, the derived type can possibly be a bit slower than an integer. So maybe not a good idea for small functions in hot loops. But for IO functions, the possible overhead is probably small.

Just like integer, type(status) is thread safe, does not have any global state.

And the Pros are: extensible, can convey more rich error information such as a string.

And it is still relatively simple.

---

If we chose to go with returning just an integer, then we can document the various different errors as different integers, and then provide a function that prints a nice error message based on the integer number.

So I think the key difference to an integer is that type(status) allows to convey information that is not just the error type, but something that changes all the time --- for example which directory failed, or what error some low level command (shell) returned. As is obvious from fpm, we need to have some functionality for running commands, and if they fail, the stderr output can be put into type(status) and propagated to the user. That would be hard to do with just integers.

So it seems to me if just a simple error with no extra information is needed, the integer might be better. But if more information must be attached to the error that is only known at runtime, then I think your type(status) is the way to go.

[aradi]

Would the idea still be that if the status argument is not provided, that it will error out right away? I think this is the key principle.

Actually, originally I wanted to propose to make them mandatory. But to be in accordance with Fortrans usual way of doing things, we could make it optional, and hope, that people would always pass (and handle it) in order to obtain a robust program.

I agree, that Fortran ususally operates with scalar types and arrays of them preventing to impose derived types on the programmer. But in my opinion, this is exaclty what makes many things quite painful, needing a lot of extra-coding for basic stuff.

As for type(status), the extensibility would be very important:

• We could attach any kind of error information to ease the understanding what happened (similar to Pythons exception)
• We could extend type(status) with traceback capabilities, so that it can collect the call stack while being propagated upwards.

[certik]

we could make it optional, and hope, that people would always pass (and handle it) in order to obtain a robust program.

Why would you consider a program not robust if it does not handle the error? If the status is not provided, then the function stops the program with a useful error message. I consider this very robust and the desired behavior. If I don't want to handle the error, I want to get a nice error message and a stacktrace. If the user wants to handle the error, then the status is provided. So it seems it is robust either way.

Regarding the stacktrace --- I think it's the compiler's job to create a nice stacktrace when the error occurs. GFortran does it, although I would like it to be formatted better.

What we can do is to try using type(status) in the IO routines and see how it goes.

[milancurcic]

I overall like it, although I don't think it's feasible to use for everything. For procedures that return a single result we use functions, and if we use an intent(out) argument in functions we can't make them pure. If we trust the long-term vision of Fortran being parallel and running on emerging architectures, then writing pure functions is what we should aim for.

So, without being convinced otherwise, my suggestion would be to limit such status/error propagation to subroutines that modify variables in-place. I/O and file system stuff is I think the perfect candidate for such things, stats functions not so much.

[certik]

@milancurcic I agree. The stat functions will be used in hot loops, so we do not want to have the overhead of more general error handling there. The IO functions will have the overhead of the IO, so we can afford more general error handling there.

[aradi]

Of course, this error handling mechanism is not meant for functions at all. Especially numerical functions have better ways of signalizing errors by returning a specific value (e.g. nan).

I'd propose to use this error-handling mechanism in those cases, where otherwise an error stop would have been called. IMO, a library, which calls an error stop in a deeply nested internal routine instead of propagating the error back to the consumer is a true nightmare and can not really be considered being robust.

[everythingfunctional]

There are 2 schools of thought I think on having an error stop in a library procedure. On the one hand, the error is unlikely to be helpful to a user of the program, as they're unlikely to be able to deduce why their input caused an error in that procedure without the rest of the context, which isn't available to that procedure to print out.

However, if such an error occurs, it is more likely a bug in the program, the procedure was called with invalid inputs, and that's on the caller. You need to fix your program.

So you could take the stance that, here's the requirements of calling this procedure, if you violate them that's on you, or, you can strive for "total functions", that can gracefully handle all possible inputs, but force the caller to deal with potential errors.

I generally like using libraries that strive towards the latter, as it makes explicit in the interface that things might go wrong, but there are of course performance penalties, and there's nothing wrong with a procedure taking the stance of "if you call me with bad inputs, I crash".

[wclodius2]

I consider a procedure that only calls ERROR STOP when it encounters a problem to be a nightmare, but I also consider one that passes a status flag up to a calling procedure, that represents a problem a calling procedure can't be expected to handle, to also be a nightmare. Instead, a procedure, if it encounters a problem it thinks is unhandleable, should print a detailed error message describing the type of problem, and the location where it was found, and then call ERROR STOP. On rare occasions when the errors are genuinely handleable (e.g. a fast but non-robust method, that discovers it is having problems may pass a flag indicating that a more robust method is needed), it should pass an optional STATUS flag, that, if not present, stops the application with the detailed error message. FWIW I also consider most user errors to be unhadleable. See Herb Sutter’s paper for SC22/WG21, "Zero-overhead deterministic exceptions: Throwing values”, for a discussion of the problems with trying to handle user or allocation errors.

[certik]

Yes, I think we all agree to print detailed error information before calling error stop.

…

On Thu, Jul 23, 2020, at 10:00 PM, William B. Clodius wrote: I consider a procedure that only calls ERROR STOP when it encounters a problem to be a nightmare, but I also consider one that passes a status flag up to a calling procedure, that represents a problem a calling procedure can't be expected to handle, to also be a nightmare. Instead, a procedure, if it encounters a problem it thinks is unhandleable, should print a detailed error message describing the type of problem, and the location where it was found, and then call ERROR STOP. On rare occasions when the errors are genuinely handleable (e.g. a fast but non-robust method, that discovers it is having problems may pass a flag indicating that a more robust method is needed), it should pass an optional STATUS flag, that, if not present, stops the application with the detailed error message. FWIW I also consider most user errors to be unhadleable. See Herb Sutter’s paper for SC22/WG21, "Zero-overhead deterministic exceptions: Throwing values”, <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf> for a discussion of the problems with trying to handle user or allocation errors. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#224 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAFAWHYE3IFPQESMTZGE33R5EBOBANCNFSM4PFPIXJQ>.

[jvdp1]

Yes, I think we all agree to print detailed error information before calling error stop.

Indeed, I think we agree all on that. However, this means that functions are not allowed to be pure, as currently in stdlib_experimental_stats (see example here.
Any ideas how to resolve that for functions, since this proposition doesn't seem to cover functions?

[aradi]

Of course, error stop with message is better. But often, the error is not caused by a bug, but by wrong user input (e.g. paths, some numerical values). And I find it much nicer, if the simulation package writes out a qualified error message (Error while trying to read the specified parameterization file (input.txt:23)) instead of (Could not read 'something.dat. Or The mixer scheme failed, try to use a different mixer settings versus Unable to solve linearly dependent system of equations.

As for functions: I think, we should only allow for functions which either never fail or can report their failure via a special value of their return type (e.g. NaN).

[jvdp1]

As for functions: I think, we should only allow for functions which either never fail or can report their failure via a special value of their return type (e.g. NaN).

I am not sure I fully agree with that. For example, for the function mean, the dimension dim can be provided (with 0 < dim < maximum_rank_array). Currently if the user provides a wrong dim, a message is printed and error stop is called.
This is similar to what happen with the intrinsic sum (with gfortran):

Fortran runtime error: Dim argument incorrect in SUM intrinsic: is 3, should be between 1 and 2

I don't think that returning NaN in this case would be correct, but this strategy would allow pure functions.

[certik]

However, this means that functions are not allowed to be pure

It seems error stop can be in pure functions, at least with GFortran. We should check the Fortran Standard on this one.

This function indeed does not compile:

pure integer function f(x)
integer, intent(in) :: x
f = x+1
stop "ok"
end function

with:

a.f90:4:9:

 stop "ok"
         1
Error: STOP statement not allowed in PURE procedure at (1)

But this one compiles:

pure integer function f(x)
integer, intent(in) :: x
f = x+1
error stop "ok"
end function

[aradi]

According to MRC: "Execution of an error stop statement causes execution to cease as soon as possible on all images, so there is no need to disallow it in a pure procedure. It is now allowed ..." (It is apparently a Fortran 2018 thing).