[Gdal-dev] Changing How GDAL Reports Errors

[Frank Warmerdam]

On 9/2/05, Steve Soule <stsyo3lwdia4 at vexcel.com> wrote:
> 4.  For some errors, rather than use the normal mixture of the above
> three techniques, GDAL throws an exception, usually std::bad_alloc.

Steve,

As Bill suggests, code throwing exceptions and not trapping them
are in violation of the design.  Does "new" throw std::bad_alloc
if the allocation fails?  I have generally taken the view that if a small
allocation fails in GDAL it will just "fall over and die" (ie. a fatal error).
I prefer this to trying hard to handle all possible small memory allocations.
So, I am inclined to do nothing to trap out-of-memory errors in the new
operator.  

For other exceptions in drivers such as the OPeNDAP driver, I have
tried to add a big try block around the code and translate exceptions
into a legal CPL style error. 
 
> GDAL also has "fatal" errors that never return control to the caller.
> These errors are always reported to the error handler, but no matter
> what the error handler does with them, the program is aborted.

Well, technically you could throw an exception in fatal errors, or
use setjmp/longjmp to get out of the error handler.  However, no 
reasonable unwinding code exists so things would be left in an 
indeterminate state. 
 
> 1.  Any C or C++ client code would need to be changed.  However,
> the changes would be minor, and would generally tend to improve the
> quality of the client code.  I don't know if client code in other
> languages such as Python would need to change; I doubt it.

...

> Does anyone see any other costs worth mentioning?  Does anyone feel
> that either of these costs is a show-stopper?  Does anyone see any
> changes they would like to make to the proposed new mechanism?

A strong case can be made that GDAL should have been built
with exceptions for error handling in the first place.  However, it
was not, and I find it hard to conceive of accepting the disturbance
to the API required to convert to using exceptions everywhere.  

As GDAL dictator-in-chief, I will respectfully turn down the proposed
changes in the main GDAL codestream.  

I am interested in improvements that could be made in the existing error
handling without significant API turmoil. 

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent