[GRASS-dev] [GRASS-SVN] r63227 - in grass/trunk/scripts: d.correlate d.out.file d.rast.leg d.redraw d.shadedmap d.to.rast d.vect.thematic d.what.rast d.what.vect

[Vaclav Petras]

On Wed, Dec 3, 2014 at 12:54 PM, Glynn Clements <glynn at gclements.plus.com>
wrote:

>
> Vaclav Petras wrote:
>
> > > > The issue is this:
> > > >
> > > > GRASS 7.1.svn (nc_spm_08_grass7):~ > g.region rast=lsat7_2002_30
> > > > GRASS 7.1.svn (nc_spm_08_grass7):~ > d.correlate
> > > map=lsat7_2002_30,lsat7_2002_40
> > > > ERROR: No graphics device selected. Use d.mon to select graphics
> device.
> > > > Traceback (most recent call last):
> > > > ...
> > > > grass.exceptions.CalledModuleError: Module run None ['d.text',
> > > > 'color=black', 'line=1', 'stdin=CORRELATION', 'size=4'] ended with
> > > > error
> > > > Process ended with non-zero return code 1. See errors in the (error)
> > > output.
> > >
> > > I can't reproduce the problem. And I'm not even sure how d.text can
> > > exit with a non-zero return code without printing any error message.
> >
> >
> > I can reproduce it. Are you sure you don't have MONITOR or
> > GRASS_RENDER_IMMEDIATE (or any other if it matters) set? I start GRASS
> > session (without any special shell environment) and I get it.
> >
> > The error is the beginning, r.text is printed first (that's ERROR:... I
> > think), then the error from the main process is printed (Traceback....).
>
> Er, right; I got confused by the fact that the script changes used
> exactly the same error message as d.text (which is a leftover from
> 6.x).
>
> The issue has been fixed in r63361. The issue was first introduced in
> r46984 and incorrectly "fixed" in r46999.
>
> In GRASS 7, it isn't (or shouldn't have been) necessary to set
> GRASS_RENDER_IMMEDIATE. This variable only exists to choose a driver
> other than the default (cairo if supported, otherwise PNG).
>
> > I think the solution is try-except or calling the function(s) with with
> > secret `errors` parameter set to 'exit'.
>
> No. There's no point in catching exceptions if you aren't going to
> handle them.


I agree. If it is not probable that the module will fail, I think you don't
have to do try-except. In case of error you get the traceback which is
great because it will help you identify the problem (and for example handle
the errors in a better way if the original premise about error not being
probable was wrong). But it also depends on what you call handling.


> If we want to avoid the tracebacks, we should find a
> solution which works globally,


I'm not sure if we want to avoid tracebacks because hiding traceback does
not mean that the error is not there and you might be just loosing valuable
info about the place of the error. However, we have already
set_raise_on_error(), so this would be similar.

But I'm convinced that exceptions (and tracebacks) are good default because
this is how Python works and it provides the largest amount of information.


> not require each and every script to
> manually handle exceptions from each and every called module.
>
> This would be bad but I think if script author wants one big try-except
for several module calls I think that it is OK if a message saying what
happened from the point of view of the script is provided.

--
> Glynn Clements <glynn at gclements.plus.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20141205/8a4784f9/attachment.html>