[gdal-dev] Of errors and their treatment in bindings

[Howard Butler]

On Sep 17, 2010, at 7:12 AM, Ari Jolma wrote:

> Folks,
> 
> I added binding to VSIStatL (my idea is to start using ReadDir from GDAL and I need to know if something is a file or a directory).

Why not use the more natural (to you the Perl programmer) facilities your language provides for determining this?  In my opinion, this adds a lot binding complexity for very little gain.

In Python:

os.path.isdir(mytarget)
os.path.ispath(mytarget)

Why reimplement this in the GDAL bindings?


> 
> That requires, in my mind, a new typemap, which I call RETURN_NONE_TRUE_IS_ERROR as the VSIStatL in port returns 0 on success but it does not call CPLError.
> 
> Similarly we have from earlier IF_FALSE_RETURN_NONE, which is used now only in once case (GCPsToGeoTransform) where GDAL non-zero return means error condition and GDAL does not call CPLError (the docs explain possible causes of error). And we have IF_ERROR_RETURN_NONE. IMHO these should be called RETURN_NONE_FALSE_IS_ERROR and RETURN_NONE.
> 
> Sometimes the GDAL API uses plain int and sometimes CPLErr. We need to tell Swig that it should drop the return value. If int is used, it must be shadowed with typedef int something_else. I renamed the typedef from FALSE_IS_ERR to RETURN_NONE which is hopefully a bit more descriptive.
> 
> I guess if we could trust GDAL to call CPLError always we could simply use one RETURN_NONE typemap and not three.

Unfortunately, it's too late for that :/

I don't disagree with any of the above situational information regarding typemaps and what's necessary to write bindings for VSIStatL.  I just disagree that we need public, calcified, never-to-be-changed-ever-again bindings for a compatibility layer that users can already get from their language's facilities.  With help.  And fewer bugs ;)

Howard