On Wed, Sep 23, 2009 at 11:15:51PM -0500, Hezekiah M. Carty wrote: > On Wed, Sep 23, 2009 at 10:41 PM, Hazen Babcock <hbabc...@mac.com> wrote: > > Hezekiah M. Carty wrote: > >> > >> It has been several months since this was brought up, but I think that > >> this is still worth addressing. ??Having the PLplot exit a program > >> completely can be a shock, particularly when using the library > >> interactively. ??I think that making these changes pre-5.10.0 would be > >> better than post-5.10.0. ??Otherwise I expect they would have to wait > >> for a 5.11.x development release due to the likelihood of an API > >> change. > > > > If you are using a language that supports exceptions and callbacks from C > > you can override the PLplot's default exit() behavior. > > I attempted that this evening with OCaml after adding plsabort and > plsexit support to the language bindings. Unfortunately, I found that > plsexit and plsabort do not override the plabort and plexit behavior. > Instead, the provided callbacks are called just before the default > actions are taken. So plabort always prints out its standard message > and plexit always calls plend() and exit(). This is stated in the > documentation for plexit and somewhat ambiguous for plabort. I had > only read the plsexit and plsabort documentation before binding these > functions so this was a bit of a shock to me. > > Is there a different way to override the plexit and plabort calls?
No - not in the current code. I think changing plabort to not print the standard message if there is a custom abort handler would be perfectly reasonable. The custom abort handler gets the message string and could reasonably be expected to print it. This would only be a change if you are already using a custom abort handler, and why would you do that if it doesn't override the default behaviour? > > > Thoughts about how we would implement this? Would we have to change every > > function in API to return a success or failure code? This seems like a huge > > change, the kind of change that would take us from version 5 to version 6. > > After looking through the code Andrew mentioned in his post, this does > look like a very large task. If there is no way currently to fully > override plexit and/or plabort, changing plexit/plabort to allow this > may be a more acceptable behavioral change without having to jump to > version 6.0. > > Is this an acceptable change, pre-5.10.0? It would not affect the > default behavior, but it would change how plexit and plabort act when > custom callbacks are defined. We do have an errmsg and errcode variable pointers in the plplot stream which are set via plsError. Calls to plabort will set these variables if they exist. This could be used to return error values for calls to plexit without altering all the return values of plplot functions, but this is a rather convoluted way of doing things. This does not work well except for C / C++ because you can't always easily pass a variable pointer in from another language. We could work around this by providing a plgError function which returned the value of a C error variable. My feeling is that an "easy" solution would be to allow the default exit handler to be completely replaced and to use these error codes, or something similar, to get the return status. This is not a big API change. Following all calls to plexit with a return statement should avoid internal problems with code continuing when it is not possible to do so. A better, but much more major, solution would be for plplot functions to have proper return codes to flag errors. This is a major API change, but since almost none of our functions have return values at present it would not stop most code being recompiled. Of course that code would not properly check for error conditions, but it would at least run. For some languages, like C++ and java, which support exceptions, then we could replace the default error handler with one which throws an exception. I quite like this idea, and I may well implement this, although again this is a big API change since user code will now have to be prepared to catch the exceptions. Whatever we do an option is always to provide a backwards compatibility exit handler which does still call exit. We could even have a compile time option to make it the defaul. That way users with old code need only a minor alteration to carry on as they are. Any thoughts? Andrew ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
