[Gdal-dev] Changing How GDAL Reports Errors

[Frank Warmerdam]

On 9/6/05, Pete Nagy <Peter.Nagy at vexcel.com> wrote:
> 
> It's always nice to avoid API modifications that require changes to code,
> like adding a pointer to an error structure for c function calls.
> 
> Here's a possible alternative.  How about, functions return a non-zero
> value to indicate an error occurred, so existing code can continue to
> check for error-or-not status.  Behind the scenes, though, each function
> could call something like CPLGenerateError to create an error of a
> particular type and message, which would add it to a list, and return the
> list index - which would be the return value for the failed function.
> Therefore, any calling function that wants more information about why a
> function call failed could call something like CPLGetErrorType(ret_val) or
> CPLGetErrorMsg(ret_val).

Peter,

Errors are internally posted using CPLError(), and applications can
push a handler callback to "stack up" errors in a list if desired.  The
only aspect of what you currently propose that is not addressed is
having the API functions return explicit error indices but I'm not
sure in what contexts that would be particularly useful.  After any
given call it is possible to get the last error message if an error
occured. 
 
> Maybe this would also be easier to make thread safe, and if you plug in a
> GUI to report errors to the user it would have access to errors from all
> threads - wouldn't it?

Currently each thread only has access to it's own errors, but an 
application error handler can always push them through to some
central application error list if needed, along with the thread of
origin. 
 
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