On Thu, Nov 03, 2011 at 10:38:27AM -0700, Alan Irwin wrote: > On 2011-11-03 09:14-0000 Andrew Ross wrote: > > > Steve, > > > > This is not at all a stupid question. In fact, it is rather an unfortunate > > historic artefact of plplot. In my opinion, libraries should never call > > exit(). Libraries should return control from a function call as gracefully > > as possible and set an error code. It is up to the application to decide > > what to do from there. For interactive languages then calling exit() is > > exceedingly irritating, just because of a plotting error. This topic has > > come up on the list before, but to fix it requires all plplot functions > > to return error codes. This is a major API change and would also require > > a lot of internal work to ensure errors were handled gracefully. Sadly C > > does not offer a nice way of exception handling unlike some more modern > > languages. > > Hi Andrew: > > I agree this is an important issue that we need to solve to make > interactive use of PLplot a much nicer experience. However, I > am not sure it needs to be solved with a massive API change. > > Here are the current rough plexit statistics: > > software@raven> grep plexit drivers/*.c src/*.c |wc -l > 228 > software@raven> grep plexit drivers/*.c src/*.c |grep -iv mem |wc -l > 97 > > The second command attempts to eliminate the "out of memory" ones from > the result since I assume you do not want to do anything other than > exit for such a major overall system problem.
Even then I don't think it is up to plplot to exit. This is the programs responsibility. You wouldn't want malloc to exit your programme if memory allocation failed. Why should plplot be different? If we tackle the problem, we should do it properly. > I am also sure most/all of those ~100 plexit calls in our code have > been done as a "quick fix" when we should have called plwarn instead > and then made some sane assumptions to continue when that is possible > or otherwise do a quick return instead with no plotting action. I certainly agree about that. A thorough audit of the existing calls to plexit would be a good start. > Here are my preliminary thoughts on how to deal with this problem: > > i. Encourage plexit for truly bad but extremely rare situations. So > every call to malloc or calloc should be checked, and for the > unsuccessful case, call plexit. But I suspect that is the only > case where plexit should be called. > > ii. Replace all other calls to plexit with a call to plwarn instead. > There are two cases to consider here. > > + Public API. Replace plexit with plwarn and continue with the > plot when that is possible or do a quick return otherwise. If > our interactive users get a plwarn message when they make a > mistake, and in addition no plot when it is a really bad mistake > that should be sufficient, and I think a return code in addition > would be overkill. The large advantage of this approach is no > API change would be necessary. > > + Private functions. Presumably some of our private functions > that are called by our public API routines currently call plexit > themselves. For this case we should also replace the call to > plexit with plwarn, but we should also return an error code to > our public API routines which should then do a quick return with > no plotting action for non-zero return codes. > > My hope is these preliminary thoughts will encourage discussion, and > ultimately a concrete plan that we can all work on together to > eventually produce PLplot libraries that never exit except for the > out-of-memory case. I agree about your 2 classes of error above. One other additional option is to have some sort of global error flag, or a new function to check the plplot error status. For the public API a warning could also set the error flag. That way new code could check for errors, but existing function return values would not change so existing code would still work with a recompile against the new version rather than potentially requiring changes. I don't like global variables, and having to poll the variable / error function after every API call that could fail is tedious. Changing the return value from void to int would actually probably be no more invasive. A recompile would be required anyway for an API (and hence soname) change, but old code would not need to be modified - it would just ignore the return value. Anyway, I will try to start looking through the plexit calls to see if we can downgrade some of them / pass the error back in a graceful manner. Hopefully this will promote some debate. Andrew ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
