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

Sören Gebbert soerengebbert at googlemail.com
Fri Sep 28 16:08:47 PDT 2012


Hi Glynn,

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

That's the behavior i would support.

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

Yes.

> If you are planning on catching the exception, a normal exception
> (i.e. a subclass of StandardError) should be used.

I think we can keep ScriptError for this case.

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

While implementing this, can we use the "raise_on_error" flag to
enable the raise of a ScriptError exception in fatal()?
It would be only a simple modification of the current code i guess.

Best regards
Soeren

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


More information about the grass-dev mailing list