On Fri, Aug 15, 2014 at 8:55 PM, Hazen Babcock <hbabc...@mac.com> wrote: > On 8/14/2014 6:00 PM, Phil Rosenberg wrote: >> Hi Hazen >> The approach of just don't call exit and see what happens was also my first >> thought. Then the first case i looked at was plscmap0n, which attempts to >> set the number of colours in cmap0, this is called by plspal0, which >> immediately assumes the call has succeeded and attempts to assign colours to >> cmap0. If the malloc call actually failed, then the memory is set to null >> and we'll get a segfault. > > I guess I favor an opt-in rather than the current opt-out strategy for > plexit(). However it is true that both are going to land you in the same > place, unless you have a special error handler your program is going to > crash with a (possibly cryptic) error message. > > At this point I agree with you that adding an error flag to the stream > which the user can check is the way to go. Changing all the functions in > all the bindings would be extremely disruptive. > > Cairo and GTK are C I believe, it might be worth a look to see how they > handle this. >
This seems to be roughly equivalent to how Cairo handles errors: http://cairographics.org/manual/cairo-Error-handling.html This would be a nice change for plabort calls as well. It would allow (relatively) safe programmatic access to error information which would be particularly useful for language bindings which may want to translate these error states into an exception, special return value or other language-appropriate response. Hez ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
