[Gdal-dev] SWIG Exceptions for C# Bindings

Frank Warmerdam warmerdam at pobox.com
Sat Mar 17 14:49:09 EDT 2007


Tamas Szekeres wrote:
> 2007/3/17, Ari Jolma <ari.jolma at tkk.fi>:
>>
>> I'd say we should add checks and calls for CPLError for null values like
>> this into the bindings layer.
>>
>> I did this for a number of methods in ogr.i, for example into
>> OGRFeature::GetFieldDefnRef. The simple reason is that if the null gets
>> into the scripting language layer, it will create a core dump, which is
>> not acceptable behavior, and this is the last place where it can be done
>> (at least in the case of Perl). I know there are still many cases in
>> which this happens since I get core dumps if I'm careless in coding with
>> the Perl bindings.
>>
>> Could we adopt the policy of always throwing an exception in a case of
>> errors in the bindings?
>>
> 
> Generally I have no objection. But why don't we generate the error at
> the original place?
> 
> Like:
> 
> OGRLayer *OGRPGDataSource::GetLayer( int iLayer )
> {
>   if( iLayer < 0 || iLayer >= nLayers ) {
>       CPLError(CE_Failure, 1, "Invalid argument iLayer in GetLayer");
>       return NULL;
>   }
>   else
>       return papoLayers[iLayer];
> }

Tamas / Ari,

Once upon a time OGR was essentially error return code oriented and avoided
using CPLError().  However, this proved to be a liability and so I've since
been using CPLError freely, but it is certainly not consistent.  I would
agree 100% with issuing CPLError()'s in OGR pretty much anywhere that errors
occur which would improve the exception generation in the wrappers.

Feel free to commit the above change - but please use symbolic constants
for CPL errors - normally CPLE_AppDefined if you aren't sure what to use.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org




More information about the Gdal-dev mailing list