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

[Glynn Clements]

Sören Gebbert wrote:

> > 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().

The original behaviour was that error() simply called "g.message -e",
while fatal() also called sys.exit().

> >> 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().

Personally, I would favour simply restoring the original behaviour of
error(), i.e. print an error message then return. fatal() would always
be fatal in the sense of not returning, but you'd have a choice of
whether it throws SystemExit or e.g. ScriptError.

If you're not planning on catching the exception, SystemExit is
preferable as a program terminating due to an uncaught SystemExit
exception doesn't print a backtrace.

If you are planning on catching the exception, a normal exception
(i.e. a subclass of StandardError) should be used. SystemExit isn't
supposed to be "permanently" caught. Rather, it allows context
managers ("with" statement), try-finally, and try-except-raise to be
used to clean up on the way out.

For simple clean-up operations, atexit.register() is sufficient.

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