Hi Alan
Proof of concept was a little more than 20 or so lines 😉
I'll pull out the code I started and check where is stands.
Phil
Sent from my Windows 10 phone
From: Alan W. Irwin
Sent: 15 July 2017 21:50
To: Phil Rosenberg; Ole Streicher
Cc: Hazen Babcock; andrewr...@users.sourceforge.net; PLplot development list
Subject: First proof-of-concept step requested to implement PLplot errorhandling
On 2017-07-15 11:49+0200 Ole Streicher wrote:
> Another (probable longer-standing) topic would be the use of exit() in
> several libraries in case of error. That usually has the disadvantage
> that it makes debugging more complicated, since you don't get a
> stacktrace; abort() may be the better solution here. Any thoughts about
> that?
To Phil and Ole (with CC to Hazen and Andrew):
@Phil:
There is a key question for you at the end.
@Ole:
Here is some background on the issue you brought up above.
An even more important issue with exit that concerns PLplot developers
is, for example, some poor guy has been working on some interactive
session for 4 hours, (e.g., octave) and then attempts to finish up by
plotting his results, but he makes a wrong PLplot call ==> exit, loses
all those 4 hours of work! Not pretty!
The obvious solution is to implement a proper error handling system
for the PLplot libraries, bindings libraries, and device drivers that
avoids the use of exit and simply propagates an error condition to
whatever library or user routine calls PLplot routines if something
goes wrong anywhere in any of the PLplot-related source code.
We have discussed here fairly recently the best way to implement such
an error handling system. There have been two schools of thought about
how we implement that which I will attempt to summarize here.
1. Implement our error handling using normal C methods. That is,
change our API to return an error code for each PLplot routine that
can possibly have an error condition or which calls a PLplot routine
that itself could have an error condition. (This turns out to be most
PLplot-related routines). Then those error conditions codes must be
checked and propagated further if necessary after virtually all
returns from PLplot routines that occur within the PLplot libraries,
bindings libraries, and device drivers.
2. Implement our error handling system using longjmp and setjmp
See <http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html>
for an example of how to use those two C library routines (both
available since c89 and also supported by Windows) to implement
exception handling in C that is quite similar to exception handling in
C++. I believe when Phil Rosenberg suggested a longjmp/setjmp based
error handling system he was unaware of this example so his proposal
likely varied in many details from this example. But the overall
principle was the same which is you can use these two functions to
avoid the laborious process of having to propagate error codes via
function return values.
Andrew Ross and Hazen Babcock liked the first idea because it is the
standard C way to implement error handling. Phil and I liked the
second idea because it is a lot less work (the PLplot call graphs are
extraordinarily complex so there are potentially huge numbers of
Plplot routine return values to check within the PLplot libraries,
bindings libraries, and device drivers).
The above reference on C exception handling mentioned an issue many C
programmers have with longjmp/setjmp which is they are completely
unfamiliar with their use. And I think PLplot developers (including
me) do indeed have such unfamiliarity concerns. So to help us get
more familiar with their use, I asked Phil the last time we discussed
this to implement a simple proof of concept of his idea (e.g., a
modification of plexit that unwinds the stack and delivers an error
message to a single convenient place in our PLplot core library
(likely our library initialization) where setjmp is called to set
everything up.) I suspect Phil just plain forgot about that request
due to other time pressures on him so I am taking this opportunity to
make that request again. :-)
@Phil:
I am still just as unfamiliar (except for what I read in man pages) as
the rest of our developers with longjmp/setjmp. So are you game to
implement such a simple proof-of-concept to help us become more
familiar with those two routines?
If so, how about dealing with it right away (after all, I think we are
only dealing with something like ~20 lines of code) to avoid losing it
again in your stack of PLplot e-mail? This variant of plexit should
only be compiled if the user specifies the -DHAVE_ERROR_HANDLING=ON
experimental CMake option which should default to NO to provide
sufficient safety that if you act fast you can safely merge this with
the master branch in time for the 5.13.0 release.
The goal of such a simple proof of concept would merely be to confirm
the stack was properly unwound by longjmp with a message right after
the single place in the PLplot library that you call setjmp during
library initialization. If that call returns 0 (i.e., it is the
initial call made during library initialization) then no message would
be generated, but it it returns non-zero (i.e, the result of longjmp)
then generate a "this proof-of-concept is working" message before (for
now) exiting just like ordinary plexit does. So this simple proof of
concept would be restricted to inside the PLplot core library, and the
gory details of how to propagate error reporting across the boundaries
of our PLplot libraries, bindings library, and device drivers would be
ignored for now. Of course, this proof of concept would be far from a
full solution for our much needed error handling system, but it could
be a very important first step in achieving that important PLplot
goal. So how about taking that first step now?
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
