[GRASS-dev] GRASS scripting Python API error/fatal handling

[Glynn Clements]

Sören Gebbert wrote:

> Dear developers,
> i am confused about the implementation of grass.error() and
> grass.fatal() in the grass.scripting library.
> 
> >From my understanding should the grass.error() function simply print
> an error and grass.fatal() should either exit or call an exception so
> that the GUI or a module developer can catch a fatal error. The
> grass.set_raise_on_error() function allow to throw an exception in
> case an error occurs that is not fatal to the processing. But it is
> not possible to catch a fatal error because simply exit is called.
> Can grass.fatal() be catched when raise_on_error is true, since it
> calls internally grass.error()? If yes  raise_on_error must be set by
> the GUI to catch fatal error. BUT all errors that may not be fatal for
> module processing will raise an exception too?

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.

> That gives me the impression that grass.fatal() should never be called
> in a Python library function since otherwise the GUI will crash?
> 
> Howto implement library functions that face an error but should allow
> i.e. the GUI to keep on processing? Printing an error and raise a
> ScriptError exception should do it i guess. But what to do in cases
> the same library functions are used in modules where the error should
> be handled as fatal? Raising an exception will in this case confuse
> the user, hence calling fatal would be more appropriate.

In the absence of try/except, the only real difference between raising
ScriptError and SystemExit is that the latter won't result in a
backtrace being printed.

> IMHO Python modules should show the same behavior as the C and bash
> modules and avoid to print implementation language specific errors.

Python has exceptions, C doesn't. If C had exceptions, we would use
them instead of the "fatal error" mechanism, as exceptions are easier
to catch (catching fatal errors requires the use of setjmp() and
longjmp(), which can be messy, and nesting handlers is even worse) and
provide the same default behaviour (i.e. a program which doesn't go
out of its way to handle the error will terminate).

> 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?

-- 
Glynn Clements <glynn at gclements.plus.com>