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

[Even Rouault]

Selon Ari Jolma <ari.jolma at gmail.com>:

> On 11/30/2011 10:20 PM, Even Rouault wrote:
> >
> > Hi SWIG binding users/devs,
> >
> > Any opinion on http://trac.osgeo.org/gdal/ticket/4360 ?
> >
> > """After the changes done in
> > http://trac.osgeo.org/gdal/changeset/11529 /
> > http://trac.osgeo.org/gdal/ticket/1635 , any CE_Failure error emitted
> > by CPLError() in the Open() method of GDAL and OGR drivers, and not
> > cleared, will cause the swig bindings to return a null dataset, even
> > if the driver returned a valid one.
> >
> > Sometimes those errors are not critical, and users regularly complain
> > (last occurrence is
> >  http://lists.osgeo.org/pipermail/gdal-dev/2011-November/030960.html
> > <http://lists.osgeo.org/pipermail/gdal-dev/2011-November/030960.html>
> > ) that they can open them successfully with C/C++ API, but not from
> > Java/Python/etc, so I'd suggest the following patch that adds a
> > bIgnoreErrors option, that if turned on will reset the error flag in
> > the case discussed here. By default, the new option is not turned on. """
> >
>
> GDAL has warnings, failures and fatal errors. I don't know the
> semantical error between a failure and a fatal error and they are
> treated the same in the bindings.

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.

So remains the difference between a warning and a failure. I'm not sure there's
really a perfect way of discriminate them.

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.

>
> I usually think about these from the point of view of somebody using a
> GUI and I don't see a checkbox in open vector dataset dialog box for
> "ignore errors".

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

>
> I'm concerned about the viability of the returned dataset object - it is
> ok if the user is warned and given a not perfect object, but it is not
> ok to return an object, which may lead to core dumps or other bad things.

Drivers should return a NULL object in that case. The C/C++ utilities in GDAL
only check if the pointer is NULL or non-NULL. They don't check the error flag.

Even