[gdal-dev] exceptions in bindings

[Howard Butler]

On Jul 24, 2008, at 2:31 AM, Ari Jolma wrote:

> Hobu,
>
> Still looking at the GetHistogram binding, one thing that puzzles me  
> is the CPLErrorReset call. It is there and it is also in all the  
> Operations.i bindings. In Perl that leads to it being called twice  
> (which probably does no harm), because all methods are wrapped by  
> cpl_exceptions.i with it:
>
> CPLErrorReset();
> $action
> CPLErr eclass = CPLGetLastErrorType();
> ... check the eclass and possibly throw an exception
>
> But cpl_exceptions.i does not seem to be used by Python, which has  
> its python_exceptions.i. It is very similar to cpl_exceptions.i but  
> lacks the CPLErrorReset() call. I don't understand the comment in  
> python_exceptions.i:
>
> "This was the cpl_exceptions.i code. But since python is the only  
> one different (should support old method as well as new one) it was  
> moved into this file."
>
> Is there a particular reason for not having CPLErrorReset() in the  
> %exception for Python? Does the comment mean that somebody thought  
> of deleting cpl_exceptions.i?
>

I'm not positive, but I think the rationale for this is in the Python  
case where we are using return codes rather than exceptions, the user  
needs to control the ability of when the CPL error reset happens.  If  
a user were to forget to call the reset due to an error in a previous  
function call, they would get an error pertaining to the wrong  
function call.  I think the CPLErrorReset calls that exist in the  
methods are to hand hold the user in this instance.

Frankly, I'd love to ditch the return code idiom for Python entirely  
and have exceptions always be on, but a certain Frank has a rather  
strong say about preserving the old behavior :).  It would be much  
simpler in a lot of ways, and tracebacks would have a lot more meaning  
in bug reports.  I find it frustrating that we can never revisit these  
kinds of decisions (because they would cause people to have to change  
some of their own code), and we must live with them forever.

I'd also love it if CPL had an error *stack* rather than just an error  
bit so I as a user and bindings maintainer doesn't have to worry about  
sequencing all of the check-the-bit, read-the-bit, clear-the-bit  
calls.   Then we wouldn't have to litter the code with CPLErrorReset  
all over the place.  I think this would be possible without changing  
our error API and could provide a lot of benefit.  If other folks saw  
it as a good thing and there was support for it, I would probably  
pursue it.

> I'm also adding the IF_ERROR_RETURN_NONE specifically for  
> GetHistogram although I think it should probably be the default for  
> Perl. The name is also misleading at least in the Perl case as it  
> really means "do not return the error code (since we're using  
> exceptions)".

For any other language besides Python (because of its history), I  
think it makes a lot of sense to not bother at all with return codes  
if there is a problem and rely on exceptions if the language supports  
it.