Re: [Plplot-devel] exit() calls

[Phil R. <phi...@ya...>]

Okay, well that seems like a quorum then. I'll start putting it into action.

Interesting that for Cairo it says it is safe to use an object if in error state. Wonder if errors get cleared at any point.

Phil

-----Original Message-----
From: "Hezekiah M. Carty" <hez...@us...>
Sent: ‎16/‎08/‎2014 12:09
To: "Hazen Babcock" <hba...@ma...>
Cc: "Phil Rosenberg" <phi...@ya...>; "plp...@li..." <plp...@li...>
Subject: Re: [Plplot-devel] exit() calls

On Fri, Aug 15, 2014 at 8:55 PM, Hazen Babcock <hba...@ma...> 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