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
