[gdal-dev] RFC 37: User context data in CPLErrorHandler callbacks
Howard Butler
hobu.inc at gmail.com
Tue Oct 25 17:01:18 EDT 2011
On Oct 25, 2011, at 1:32 PM, Ari Jolma wrote:
> On 10/25/2011 09:07 PM, Howard Butler wrote:
>>> You also did not address if/how this will be exposed in SWIG languages.
>> This RFC is not going to address integration of this capability into the usage of error handlers in the SWIG languages, but bindings maintainers are encouraged to consider how this capability could improve error handling within those languages and implement code to take advantage of it accordingly.
>
> That sounds very correct, but could you elaborate a bit how this capability could be exploited?
>
> It is a problem when the user initiates a complex process in a GUI and somewhere along the way GDAL is called ending in an error. The error report is probably not very useful to the user. Could this facility be somehow used to add to the error message ending up in the message box the user sees?
SWIG bindings code could start pushing its own error handling operations along with a void* user data to CPLPushErrorHandlerEx to capture the context of the object(s) that the error handling function corresponds to. Instead of the simple CPLSetErrorHandler-based global handlers we have now, native languages could construct their own handlers and pass the "self" of the object for which that handler corresponds into CPLPushErrorHandlerEx and then utilize that "self" object when an error or debug message occurs.
Mateusz' example demonstrates some of the concepts, albeit in a very c++'y way. http://trac.osgeo.org/gdal/attachment/ticket/4295/trampoline_set_handler.cpp I'll try to cook something up that demonstrates how it could be taken advantage of from the SWIG Python bindings and utilized as an example for the other languages soon.
> Right now the Swig interface to the error handler facility is rather minimal.
Indeed. This is mostly a result of coming from the original GDAL Python bindings into a full-force SWIG-based approach. Kevin started out with something simple, and it has stuck around.
Howard
More information about the gdal-dev
mailing list