[Plplot-devel] Error propogation

[Phil R. <p.d...@gm...>]

Hi all
We have had this discussion in the past. But I would like to reopen it.

We really really need to get id of the exit() calls in PLplot. I don't
think that we can really make any recommendation that our library is
"industrial strength" while they are their and I would be very nervous
about using PLplot in production software with them in - plus even
using PLplot for science work I have been caught out be these calls in
the past.

I think there are a few options we have got

Firstly with our internal propagation we can either do
A1) Set up our functions so they return error codes and make sure we
check these. I feel there is a tendency for this to be bad because I
know that I am inherently lazy if I am frank (and I'm sure we all have
our lazy moments) and tend to write code without these checks then
(try to) go back and add them later. Missing checks are likely to
cause segfaults or memory corruptions which are even worse than the
exit calls().

A2) Set up an error flag in PLStream which can be set on error and
checked after every function call. This would avoid having to change
functions that already return values, but still relies on manual
checks which I think will be a big weak point.

A3) Use setjmp/longjmp calls. In this case we call setjmp in the top
level of every API call and on error we call longjmp which returns the
execution point back to the point setjmp was called. There is some
extra setup time here to avoid memory leaks and other resource leaks,
but once that is done we can all write code with almost no worry
regarding error propagation.

Once we decide on our internal method we need to decide how we can
inform the user. We have a number of options again:

B1) An API change so that all our functions return an error code.

B2) Make use of our current plabort call and let the user pass in a
plabort handler.

B3) If we have an error, store an error code in PLStream and add an
API function called plgeterr or similar which allows the user to check
for error after any other function call.

B4) In the C++ binding we could throw an error. Not sure if other
languages have similar throw/catch style options.

B4) Some combination of the above.

I will add there are some specific things we need to think about for
our C++ drivers. These are not so much options, but things we need to
deal with anyway.

C1) Our C++ drivers cannot be allowed to throw an error out of the
driver code and into the main C code. That would potentially end up
with the throw going all the way out to the user's top level code
which may be in C, Fortran, or any other language that can't deal with
it. Note that even if the driver doesn't call throw, it may call
either something in the stl or another driver (in Qt or wxWidgets for
example) that does throw. This is easy to avoid by wrapping the intry
points in try blocks. I have done this for wxWidgets, but haven't
checked the other C++ drivers to see if they are the same.

C2) If we go for option A3, then we cannot allow longjmp over C++
code. This is because nontrivial destructors are not called when
longjmp is called and if objects with these destructors are jumped
over then the result is undefined behaviour - which again is worse
than exit calls.

The fix for C2 - and I think this would be a good thing anyway - would
be to have a specific driver API. This would allow us to have setjmp
calls when we enter that API and avoid jumping over drivers. I think
this would be nice in general as it is not well documented how to
write a driver and a proper driver API would address that.

I am well aware that the use of setjmp and longjmp is very divisive.
So my intention is to work this code up only for the case of memory
allocation failures. This code will consist of:
D2)A set of plmalloc, plrealloc and plfree fuctions which will replace
the usual versions. As well as allocating/freeing memory these
functions will record the allocations in the PLstream.
D1)PLTRY, PLENDTRY macros which will go in each API call. PLTRY will
have the setjmp call. This will be followed by the current code in the
function as it is now then PLENDTRY will deal with what happens if
longjmp has been called - it will check for memory allocations
recorded in the PLStream and will free them. For now it will then just
call exit() so we get the same behaviour but this can be changed later
if we want to go down this route. Once we have this first look at how
setjmp/longjmp can work in our code then I think it will be easier for
us to make an informed choice about the A options.

Does that sound sensible to people? If anyone would like to look at
what would be involved in doing a similar thing using the other
options then it would be really nice to be able to compare the work
and admin/code practices needed for those too.

Phil