[Gdal-dev] CPLErrorV change to better support scriptland

[Kevin Ruland]

Frank:

Fair enough solution.

But I think I could trump the whole thing and let you do what you need
to do.  Suppose in language binding X (where X = python :) I write my
own special little ErrorHandler.  And further this ErrorHandler does not
return to the caller (CPLErrorV) but rather throws.  Then in the Swig
binding world, I catch this throw and convert into an appropriate
exception in language X.  Of course, there are some issues:  1)  Need to
have swig generated try blocks around *every* native call.  2) I don't
know how this would interact with user supplied error handlers.  The
user supplied error handler would have to raise/throw/whatever in order
to trump the abort().  This might be fairly simple to do in the ScriptX
<-> ErrorHandler mapping wrapper, but there could be some rather wierd
issues.

Kevin

Frank Warmerdam wrote:

>On 6/19/05, Kevin Ruland <kruland at ku.edu> wrote:
>  
>
>>Frank,
>>
>>One of the things Shawn expressed dissatisfaction from was for some
>>problems, gdal will abort() and the interpreter would go away very
>>quickly.  This of course, is not very nice behavour.
>>
>>The problem is very apparent in the NG swig code because I don't do any
>>special parameter checking prior to calling the underlying method.  So
>>for example, say "out.tif" only contains one layer, then if I do this:
>>
>>f = gdal.Open( 'out.tif' )
>>f.GetRasterBand(42)
>>
>>The underlying GDALDataset::GetRasterBand() gets the numer 42 with no
>>prior checking.  It rightfually decides this is a good time to issue a
>>CPLError( CE_Fatal,....).  The problem is CPLErrorV will call abort() if
>>the error class is CE_Fatal.  Bye bye python.
>>
>>I see that in the old bindings, you place extra checks in the script
>>side for the parameters. This is not very amenable to supporting
>>multiple bindings.
>>
>>Is there any way to remove this abort() entirely and leave it up to the
>>application to decide if a problem is serious enough to abort?  It just
>>seems more polite but I don't understand what the implications would be.
>>    
>>
>
>Kevin,
>
>I'm not really keen on removing the abort() for fatal errors, but
>I do think that this particular error should be changed to just
>a normal CE_Failure error intsead of a fatal error.  Really the
>only use I see currently for the fatal error is when CPLMalloc()
>fails in an allocation.  
>
>I will change GDALDataset::GetRasterBand() to issue a 
>CE_Failure error and return NULL in case of an illegal input.
>This can be then translated into an appropriate type of exception
>in python and possibly other languages. 
>
>Best regards,
>  
>