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 <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
