[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