On 2016-02-24 10:33-0000 Phil Rosenberg wrote: [Alan] >> I believe there are some 300 functions in our public and private API, >> and not all of those will be affected by this (because there are no >> error conditions they generate or they need to propagate). So I would >> estimate "hundreds" of functions rather than "thousands" would be >> touched by this propagation effort.
[Phil] > Note that some functions are called tens of times within plplot, and > with an error code return mechanism it is each call that needs a > check. That point is correct. So it is possible our C examples might never exercise a particular call chain that needs checking, or that call chain might be there to be checked, but it could be masked in tests because it is always called after a different call chain to the same function in everyone of our C examples. Nevertheless, our first line of defence is due diligence with grep which should easily find all instances where a particular routine is being called within our code base. So combining that with the test I described would likely catch the vast majority of errors in the error reporting. Therefore, I think this approach is already far better than "good enough". In any case this is a large change for users since before they could (largely) rely on PLplot to exit when there were errors and now suddenly the action to take concerning errors is on their shoulders instead. So we should write up this change extensively in the release notes including a section about how to report errors in the report system itself where there is an initial error message followed either by no non-zero return code or else some other PLplot crash before control is returned to the calling programme. But again, I think because of the due diligence noted above this would be quite a rare case for our users to contend with. > Also some functions return values; this would need > restructuring with the potential for introducing bugs - possibly very > hard to find bugs. I agree this is an issue that will need to be addressed _if_ there exists a PLplot function that currently returns a value and that function also has potential error conditions to report or propagate. However, this is likely a small problem (or may turn out to not be a problem at all) because the number of PLplot functions with return values now is quite small. >> Also, I think the editing task for propagating return codes would be a >> similar effort to the editing task for replacing the call to plexit by >> the generation of the equivalent message to stderr and an immediate >> return with non-zero return code. Note, the number of plexit calls is >> 220, > By contrast with an exception model we have less than 1 change to make > per plexit call. These can almost be done by find and replace. You may > wonder why this is less than. I imagine almost all of those are memory > allocation failures. If we create a plmalloc function which allocates > and tracks memory then this function can generate the exception if the > memory allocation fails. This removes all requirements to even check > whether a memory allocation has succeeded. Almost all the plexit calls > vanish by writing just one function, but even better all the cases > where we were lazy and didn't bother to check if our allocation > succeeded (I wonder how many of those exist in plplot right now?) get > automatically fixed. I agree that the vast majority of our current plexit calls are due to memory allocation errors and furthermore I agree with you we have been lazy about checking for such memory allocation errors so that fraction would become substantially larger if we started to check for such errors in all memory allocation cases. However, it should be noted that memory allocation errors (for debugged code that calls malloc et al. correctly) are essentially always a sign of an emergency condition where you have run out of memory due to some process leaking memory like crazy. And remember this is an extremely rare emergency condition in any case. For example, in my decades of experience with PLplot I have _never_ seen a plexit message concerning memory allocation failing. So my conclusion is an immediate exit is unlikely to irritate users in this one particular memory allocation error case. So let's simplify the problem by wrapping all our malloc calls with plmalloc (and calloc calls by plcalloc) as you suggest above. The difference with what you suggest above is I think those wrappers should rigourously check validity of arguments (i.e., sizes must be positive), automatically check for allocation errors, and if such an error is encountered print out a standard "likely out of memory" error message before doing an immediate exit. >From what you have said above, I think you will agree with me that single change would make the task of implementing a proper error report system for the remaining errors at least an order of magnitude easier. > 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. 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. [...] > Anyway, sorry if this sounds negative, it's not meant to be. As I said > I've found exceptions quite recently and they have revolutionised my > coding style, so I feel quite passionate about them. OK. By the way, I am not negative about C++, but I just don't have time right now to give it a high priority. Note that could change since even at this late date I am still learning and growing. :-) For example, I have many decades of Fortran 77 experience but only in the last couple of months have I finally learned modern Fortran as a result of my recent collaboration with Arjen on rewriting our Fortran binding. As a result I am now a strong advocate of modern Fortran (it has some high-level capabilities that are wonderfully useful in scientific computing) while before I was mainly indifferent to it. So as a result of this experience, I intend to convert both te_gen (a Fortran subproject of timeephem) and FreeEOS to modern Fortran. Live and learn.... 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
