> 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, _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
