[gdal-dev] Re: Add an option to allow opening datasets/datasources from SWIG bindings even in case of error ?

[Even Rouault]

Le jeudi 01 décembre 2011 11:03:21, Ari Jolma a écrit :
> On 12/01/2011 11:29 AM, Even Rouault wrote:
> > Fatal errors are... fatal. They will result in an abort(). They are only
> > emitted in a few places, like the CPLMalloc() routine that is guaranteed
> > to return a non-NULL pointer... or abort. So it is only designed for
> > very small allocs. For big allocs, VSIMalloc() should be used and the
> > caller should handle gracefully a NULL pointer.
> 
> I don't want my GUI app never to abort. I want to be able to catch *all*
> errors. But that's irrelevant in this case.

Sure. However I doubt you will encounter a CE_Fatal error in normal 
situations. If a CPLMalloc(10) fails, this would be the sign of something bad 
elsewhere, like a continuous memory leak, ...
I'm not aware of users complaining about that behaviour of GDAL. Perhaps they 
will dare now ;-)

> 
> But is there a way to test for failure state and convert it into a
> warning? I don't mean changing anything in GDAL itself, only add some
> clever code into the bindings? Clearing the failure state is possible,
> could we fetch the error message and raise a warning?

Something like :

char* pszLastErrorMsg = CPLStrdup(CPLGetLastErrorMsg());
CPLError(CE_Warning, CPLGetLastErrorNo(), "%s", pszLastErrorMsg);
CPLFree(pszLastErrorMsg);

However it won't undo the last CE_Failure emitted. It will re-emit it as a 
CE_Warning.

Perhaps we need a CPLSetLastErrorType() to override the error type. A bit 
hackish however.

> 
> > Yes, I agree that's unlikely. That's just about giving the capability to
> > the user (well, developer) to have the level of control needed. The
> > issue now is that there is no way from Java/Python/etc. to open those
> > datasets/datasources when a CE_Failure is emitted.
> > 
> > Another way I've imagined to avoid the bIgnoreError flag is to link with
> > the gdal.UseExceptions()/DontUseExceptions() methods that are at least
> > found in Python and Java bindings, which control if errors are turned
> > into Python/Java exceptions. One could imagine that in the
> > DontUseExceptions() mode, the check for CE_Failure done in the swig
> > wrapper is completely skipped. However I'm not sure if it exists for the
> > C# or Perl bindings. Currently there's a bUseExceptions global variable
> > in swig/include/python/python_exceptions.i or
> > swig/include/java/java_exceptions.i
> 
> That sounds too heavy to me. I don't like the global variable there,
> which leads to problems with threads at least. It exists in Perl
> bindings but it feels very much like a hack.

Yes, although in practise, I'd suppose that it is used as a one-time setting 
at the beginning of your application : either your app is designed to test for 
return codes, or it expects exceptions. But a mix of the two behaviour in 
different threads seems unlikely.