[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