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

[Ari Jolma]

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.

> Also at least in Perl there are only
>> tools for warnings and (fatal) errors. Is this a case of a failure but
>> not a fatal error and the sign is that the returned value is ok but
>> there is a failure state. Maybe we should convert the failure into a
>> warning in such a case? I guess that would be my suggestion.
> Yes, the issue is that there are hundreds if not thousands places where errors
> can be emitted, and depending on the context, an error can be just a warning or
> an error... For example, if the projection info is in another file than the main
> data file, you can have I/O / permissions problems that prevent you from reading
> that projection info, so an error will likely be emitted, but the driver is
> generally resilient to those errors and will return a valid object, even if
> projection info is missing.

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?



>
> 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.

Ari