[gdal-dev] Motion to adopt RFC 22:

[Ari Jolma]

Frank Warmerdam kirjoitti:
>>> ends up returning a (bSuccess, (x, y, z)) result which is somewhat 
>>> ackward. Is there a better way of doing this?
>>
>> Raise an exception through CPLError?
>
> Ari,
>
> I normally think of CPLError as being for "serious" errors, rather
> than expected failures.  Transformers are expected to fail when
> the input is outside the bounds of validity and I'd hesitate to
> have them calling CPLError() ever time that occurs.  Amoung other
> things, it would in some circumstances cause a flood of error messages
> to stderr.
>
> I was wondering if at the swig level it might make sense to throw some
> particular sort of exception without actually calling CPLError().  But
> I wasn't able to wrap my mind around how exceptions are handled in all
> the bindings.

The code in cpl_exceptions.i wraps calls in such a way that errors set 
by CPLError become SWIG exceptions. If UseExceptions() is called in 
wrapper initialization (as AFAIK is the default for all wrappers), the 
wrappers set a very quiet (the CPL default) handler, i.e., nothing is 
printed to stderr.

The error class defines whether SWIG exception is raised - that happens 
for failures and fatal errors. In Perl there is an additional check for 
warnings, which raise a Perl warning.

If the non-success is not really an error - or we want to leave it as 
the headache of the programmer, the method might return an empty list 
and document the behavior. This might be ok if the cause of the failure 
is always because of "input is outside the bounds" -- but as a design 
principle I think an exception (be it warning, error etc) should be 
raised as close to the place where it is detected as possible (I hate 
error messages "something went wrong in the method"), the programmer 
then should be able to choose to ignore it.

>
> I'd add in the Python case what I'd *really* like is to return None
> if success is false.  But I'm not convinced this concept translates
> well to some of the other bindings.

That's the problem with me also. I don't know the capabilities of all 
the languages. In Perl it would be possible to just return a list with 3 
elements in the case of a success and 0 if the transformation failed. 
But I think I'd vote for setting an error condition unless it is trivial 
to check whether transform will fail before it is called. An example is 
a pixel, line to x,y transformation where negative or too large pixel, 
line values are not allowed.

Anyway, I don't mind, I can always "fix" the return value in Perl 
specific parts of the wrappers ;)

Regards,

Ari

>
> Best regards,


-- 
Prof. Ari Jolma
Geoinformatiikka / Geoinformatics
Teknillinen Korkeakoulu / Helsinki University of Technology
tel: +358 9 451 3886 address: POBox 1200, 02015 TKK, Finland
Email: ari.jolma at tkk.fi URL: http://www.tkk.fi/~jolma