On 02/26/2016 05:18 PM, Alan W. Irwin wrote: > @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.
Don't worry, I promise not to start any time soon.. > 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. Such as? 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. I still favor the return value based approach. If one was to start again from scratch this is the way (I think) the library would be written, so I don't see why it would be done differently now. Yes it will probably be more work to implement, but I don't think it will be particularly hard to maintain as a compiler like gcc is more than happy to warn you if you are ignoring returned values. And yes the exit will not be clean, as there is likely to be memory that was allocated but not freed. However the possibility exists with this approach of going back in the future and cleaning all of that up, something which I don't think is possible with a setjmp() approach. Though I guess we could start with the setjmp() approach as a possibly quicker way to make the API change and then go back and clean up the internals at our leisure to use a return based approach. -Hazen ------------------------------------------------------------------------------ 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
