[gdal-dev] Towards more user-friendly error messages

[Even Rouault]

Ari,

It's funny because I myself got caught by the same issue a few days ago.
So I've just improved error reporting on shapefile layer for SetFeature(), 
CreateFeature() and DeleteFeature() operations in trunk (r17255). It was 
trivial in that case as the OGRShapeLayer object has a flag to indicate if it 
is opened in read-only or update mode.

I'm not sure there is a policy for error reporting and how it could be 
formulated if there was one ! If we can make it clearer in situations where 
it is not currently, just report it as you did.

I'd note that you can check for most operations on OGR Layers if they are 
possible by using the TestCapability() method, which is mapped to swig. For 
example, for SetFeature() with the OLCRandomWrite flag. (By the way, in that 
commit I've also fixed a few cases where the answer was not correct for other 
flags)

Best regards,

Even

Le Wednesday 17 June 2009 16:25:04 Ari Jolma, vous avez écrit :
> A colleague of mine is beginning to use GDAL via the Perl bindings (the
> bindings are not the main issue however). He makes quite simple errors,
> but is perplexed when he gets rather scary looking / uninformative error
> messages. For example he forgot to open Shapefile with update turned on
> (it is by default off at least in Perl bindings) and when he then calls
> SetFeature the error is:
>
> RuntimeError Error in psSHP->sHooks.FSeek() or fwrite() writing object
> to .shp file.
>
> Which for the initiated hints that maybe the file was opened read-only,
> but for a newbie is just scary.
>
> In this case there are two issues:
>
> - the error is at layer method, although the data source was opened
> read-only (does the layer know its data source and is it easy to query
> from the data source, how it was opened - at least in the bindings
> there's no method for that?)
>
> - where to report the error nicely, for example "Can't call SetFeature
> with a read-only layer, you moron."
>
> Is this a policy issue, or is this a case-by-case issue? How could we
> find and list the frequently made mistakes?
>
> Regards,
>
> Ari