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

[Ari Jolma]

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

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

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.

Ari

> Best regards,
>
> Even
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20111201/08bda66a/attachment.html