[gdal-dev] Catch a GDALOpen exception
Even Rouault
even.rouault at mines-paris.org
Wed Apr 6 16:34:35 EDT 2011
> 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,
More information about the gdal-dev
mailing list