[gdal-dev] Catch a GDALOpen exception

[Even Rouault]

> Even,
> 
> Yes, you are right. I missed you mean the CPLError. In case of custom
> throwing handler it will jump out of the context. I do throw exceptions
> reacting on GDAL errors, but not from within GDAL internal context,
> like the custom handler.

Yes, of course you are free to emit C++ exceptions in your code. The only 
unsafe part is when you do this in a GDAL custom error handler, during a call 
of a GDAL function that expects that the execution will continue to the 
instruction following the CPLError() call ...

I see that http://gdal.org/cpl__error_8h.html#74d0e649d58180e621540bf73b58e4a2 
states that "If the error handler function is passed a CE_Fatal class error 
and returns, then CPLError() will call abort(). Applications wanting to 
interrupt this fatal behaviour will have to use longjmp(), or a C++ exception 
to indirectly exit the function.". This is technically true, but CE_Fatal is 
really rarely used, since aborting isn't a good idea for a library. But anyway 
this doesn't specify what is allowed/recommanded in the CE_Warning or 
CE_Failure cases. Perhaps some words would be needed to discourage using 
longjmp() or throwing C++ exceptions.

Ah, and GDALOpen() isn't the only case where throwing a C++ exception in the 
custom error handler is a bad idea. Doing that in a RasterIO() call would lead 
to similar issues (block cache leaks and/or locks not being released).

> 
> >> It should be possible to react on GDAL errors and throw exception
> >> as long as certain cleanup is performed.
> >> 
> >> > (there's no guarantee that the GDAL error is emitted
> >> > before the cleanup of ressources has been done).
> >> 
> >> What error emission you mean? Returning NULL? Call to abort()?
> > 
> > An error emitted by CPLError().
> 
> Yes, that's what I was missing.
> 
> But, now this "before" should read "after", I think:
> "no guarantee that the GDAL error is emitted after the cleanup of
> ressources has been done", so leaks possible.

Yes sorry for the bad wording : it should indeed read "after".

> 
> Best regards,