Re: [Plplot-devel] First proof-of-concept step requested to implement PLplot errorhandling

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

Hi Alan et al

Please find attached some patches that show some bare bones start to using
setjmp and longjmp exception style error handling in plplot. Please have a
look at the log for a detailed description of what is going on and how it
works.

What this is: A first start with enough code to show the basic principles
of how this could work.

What this isn't: A fully working version that should go anywhere near the
actual repo. I have only tested to see if it compiles, builds and that x00c
runs. In fact I get some tcl related exception on exit, which I'm not sure
if I just caused or if it was there before.

I am sending out this super early untested code that may still have major
bugs and is based on whatever (quite old) plplot source I happened to have
on my machine so that you can see the PRINCIPLES of how it works. And
because I have other stuff on today so I might not get chance to look at
this for a while and I know Alan was keen to see something asap. So feel
free to be critical, but please not too critical :-)

Alan, have a look, have a play. Thoughts welcome.

Phil



On 16 July 2017 at 00:24, <p.d...@gm...> wrote:

> 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 <ir...@be...>
> *Sent: *15 July 2017 21:50
> *To: *Phil Rosenberg <p.d...@gm...>; Ole Streicher
> <deb...@li...>
> *Cc: *Hazen Babcock <hba...@ma...>; and...@us...; PLplot
> development list <plp...@li...>
> *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
>
> __________________________
>
>
>