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 <hbabcock@...> 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.