[GRASS-dev] GRASS scripting Python API error/fatal handling
Sören Gebbert
soerengebbert at googlemail.com
Sun Sep 23 12:02:16 PDT 2012
Hi Glynn,
thanks for your answer and sorry for the delay.
[snip]
> If raise_on_error is set, there is no difference between error() and
> fatal(); both will generate a ScriptError which can be caught; fatal()
> will never execute the sys.exit() call.
>
> If raise_on_error is not set, error() will print an error message and
> continue, while fatal() will print an error message then call
> sys.exit() (which raises SystemExit, which can be caught but normally
> shouldn't be).
>
> I'm unsure whether placing the raise_on_error behaviour within error()
> (as opposed to fatal()) was a good idea. But I don't know whether any
> code depends upon the current behaviour.
This behavior confuses me. So we need to force error() to raise an
exception to be able to catch a fatal() exception?
I would expect that catching a fatal() exception is independent from
catching an error() exception. IMHO the idea of having error() is that
an algorithm can keep on processing but inform the user that something
may be wrong in the result. The GUI or other software components force
such algorithms to raise on error() and break if they want to catch
only fatal().
[snip]
>> Hence i would like to add a "raise_on_fatal_error" flag to catch
>> grass.fatal() errors by exception and to avoid the raise of a script
>> error by calling grass.error().
>
> Can you elaborate?
Well, i think it should be named "raise_on_fatal" rather than
"raise_on_fatal_error".
I would like to have the ability to catch only the exception that was
raised by fatal() when "raise_on_fatal" is set. In this case
algorithms that call error() will be able to continue computation
since error() will not raise an exception. The flag "raise_on_error"
should still be available, but the exception that are raised by
error() or fatal() should be different. I would suggest that a
ScriptError is raised by error() and a ScriptFatalError is raised by
fatal().
Best regards
Soeren
>
> --
> Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev
mailing list