[Gdal-dev] Changing How GDAL Reports Errors

[Bill Binko]

On Fri, 2 Sep 2005, Steve Soule wrote:

> I'm posting this to the gdal-dev list to see what people think of
> the possibility of changing how GDAL reports errors.

I'd like to start with a warning: Frank W. is on vacation and may not 
reply for some time.  I would be very careful to not move on this until he 
gets back and has time to respond.  In fact, I think waiting until he's 
back and reposting this might not be a bad idea.

That being said, I have a few comments.

1) Your benefits about exception handling are well founded, and I agree.  
If a refactor of this takes place, making the C++ mechanism very similar 
to what you have below makes sense.

2) Making it easier to write effective Error Handlers may be valuable, and 
should not introduce any backward incompatibilities.

3) The places where you've found the code throws exceptions (and blows up
C code) should obviously be fixed.  I believe most would agree that this 
is a bug and not a flaw in the design.

However, I would not discount the drawback of "C/C++ client code would 
need to be changed."  I have watched a similar debate on IRC about how 
reference counting is managed, and I agree with Frank that a stable API is 
a very (very) valuable commodity.  That is doubly true with an abstraction 
layer such as GDAL.  People expect a stable target so that they are 
insulated from the various versions of the various libraries beneath GDAL.

Luckily, if you personally value elegance over API stability, you don't
have to agree with Frank's decision (if he doesn't want to disrupt client
code).  As I said during that ref-counting debate, there are a great many 
options open to you given how Frank has licensed this code.

Personally, I am not aware of the problems with thread-locality on 
Windows.  I'd be curious to see what problems you're seeing in that area, 
as my primary platform is Linux, but I'll need to be porting eventually.

Finally, I might suggest a small change to your suggestions that might
make them more palatable on the C side.  Instead of adding parameters for
Errors and Warnings, you might consider simply returning a pointer to a
structure with the errors or warnings if an error occurs, and a NULL value
if they don't.  That will allow code that looks like this:

if (someCallThatReturnsZeroOnFailure(param1, param2) != 0)
{
  handleFailure();
}

to have very little structural change and still have the ability to get 
the benefits of your changes.  It requires a choice on how to do 
allocation, etc., but requires smaller changes in the API.

I hope this helps,

Bill