[Gdal-dev] CPLErrorV change to better support scriptland
kruland at ku.edu
Mon Jun 20 09:54:03 EDT 2005
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
Frank Warmerdam wrote:
>On 6/19/05, Kevin Ruland <kruland at ku.edu> wrote:
>>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' )
>>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
>>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.
>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.
More information about the Gdal-dev