From: Phil R. <p.d...@gm...> - 2016-02-26 17:34:54
|
We have discussed a few API breaking changes recently. Error reporting, thread safety, C++ API changes and the Fortran API changes are pretty close to complete by the seems of things. Is it time to bring up the possibility of PLPlot 6 again and how we intend to manage that? Alan there are some further points below > >> 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. > 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. >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. I would suggest that we should report back on memory allocation failures rather than exit. Even with a memory allocation failure, someone using plplot in an application (e.g. in GDL) may be able to offer their user a final chance to save their work, or may be able to free some memory. I'm not sure I have ever hit a memory allocation error within plplot, but I certainly regularly hit memory allocation errors during data analysis in general. Phil |