@Hazen: Please pay close attention to this ongoing discussion and participate in it further because I don't want you to start work on the return value approach for reporting errors like you have already volunteered to do just in case the (likely) decision is made that we go with error reporting based on C exception handling instead.
More below. On 2016-02-26 17:34-0000 Phil Rosenberg wrote: [Phil] >>> I am a fairly recent convert to exceptions, but I now use them >>> throughout my C++ code, because using exceptions totally frees me from >>> having to worry about errors. I don't have to worry about checking >>> return values or anything like that, I am free to concentrate on the >>> interesting aspects of the code writing, rather than getting bogged >>> down in error checking and avoiding memory leaks. But more >>> importantly, if used in well styled code, exceptions are bomb proof, >>> they actually make it impossible to miss or fail to deal with an >>> error. >> >> [Alan] >> Is this possibility only available in C++? If so, it does not help us >> with our core C library which does need an error reporting system now. >> We do not want to use the the possibility that we _might_ move to C++ >> in the future for our core library as an excuse for inaction on this >> important topic for our current core C library. >> [Phil] > Regarding this point - C can do similar things using the > setjmp()/longjmp() function and a resource pool/tracker. It is not as > simple to implement as in C++, but I still think it would be much > easier to implement and much easier to support than trying to > propagate error codes through our internals. I still strongly > recommend a read of that book chapter and if you ever feel like > experimenting with C++ that book is excellent, although a bit out of > date now we have C++11 and beyond. > It just dawned on me that we could simply put longjmp(errcode); inside > plexit() and then all we need to do is add the code to catch this in > the API functions and the job is complete. > > Anyway please just have a read about exceptions before we make this call. @Phil: I promise to do that later today. But I have to admit you have already made a fairly convincing argument for error reporting via C exception handling, and if you look at the caller graphs I prepared there are some instances (even if we have immediate exit for memory emergencies) where the return value approach would be quite complicated. Furthermore, from my skimming of <https://en.wikipedia.org/wiki/Setjmp.h> it appears that your preferred setjmp()/longjmp() approach is usable for C exception handling just like you have claimed above. So the current status is both Hazen and I are keen to see a proper error report system for PLplot implemented soon. To the point where we were both willing to implement that with the return code method early in the next release cycle. But you have made some good arguments that primitive but easy to understand method should not be used, and instead C exception handling using setjmp()/longjmp() should be used instead as the basis for the error report system. I cannot speak for Hazen, but the major difficulty I have with the setjmp()/longjmp() method is I don't understand exactly how it should be implemented. So would you be willing to implement what you had in mind now on a private topic branch with the goal of merging it into master early in the next release cycle? (Or even in this release cycle if you can get something matured within the next few weeks.) Of course, if some part of that task was just routine editing, I would be willing to help with that, but it sounds like you might have something in mind that hardly requires much editing at all. Note, also that once you had a brand-new exception-based error report system matured and merged to master, I think you would pick up a lot of volunteers (I would be one of them) to go through our code with a fine-toothed comb looking for other errors we should be reporting (after every memory allocation, file manipulation, etc.) with that error report system. 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 __________________________ ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
