[GRASS-user] v.isochrones : error message

[Vaclav Petras]

On Sat, Apr 4, 2015 at 9:14 PM, Markus Neteler <neteler at osgeo.org> wrote:
>
>
> On Apr 5, 2015 3:07 AM, "Anna Petrášová" <kratochanna at gmail.com> wrote:
> ...
> > 7.0.0\etc\python\grass\script\core.py", line 375, in
> >> run_command
> >>     return handle_errors(returncode, returncode, args,
> >> kwargs)
> >>   File "C:\Program Files (x86)\GRASS GIS
> >> 7.0.0\etc\python\grass\script\core.py", line 310, in
> >> handle_errors
> >>     returncode=returncode)
> >> grass.exceptions.CalledModuleError: Module run None
>
> ... could this error become a bit more human readable?

There can be nicer formatting of the things which are there and better
wording. This is definitively a TODO. If this will be more (or enough)
human readable, I don't know.

Can somebody suggest some wording? (I can then change it to include all the
information available.) The sentence in question is:

Module run {module_name} {module_and_its_parameters} ended with error.
Process ended with non-zero return code {number}. See errors in the (error)
output.

https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/exceptions/__init__.py#L55

> Or have more hints in the error message?

It is hard to say what could be those hints. There is see errors in error
output. The sentence is so general (it's not pointing above or below)
because it is not clear in which context the error message is shown. In
this case for example, there is actually no error output but this is
impossible to know that with most of the start_command functions. We can
put there that it is a probably a bug and it should be reported.

It is important to realize that this error message is a fallback error
message; a message which is shown at occasions which were not anticipated
by the programmer. The traceback, as annoying as it may seem, is actually
one of the hints for fixing the bug. The 6.4 behavior is that the next
lines are executed and they may or may not fail. Even if they fail which is
desirable in error state, the error message is unrelated to the actual
problem which happened earlier. The program return code which is shown now,
even though it must be decoded by Google search, is huge luxury compared to
6.4. The traceback is a bit inconsistent with fatal_error calls which end
the execution with only with a message. The disadvantage of this approach
is that with low-level general messages such as allocation errors, it is
not clear what (stack of functions) caused them. That's one reason why
traceback is the default behavior for start_command family.

But once again, the purpose of this message/exception is to provide
information about errors which were not handled by the programmer. When
user gets the error it means that either the caller module or the called
module are not handling the situation correctly. In this case for example,
it seems according to -1073741571 (stack overflow/exhausted) that v.to.rast
does infinite or too deep recursion or does something strange with memory
(I actually don't know exactly, this general information what Wikipedia
article will tell you). If there would be return code 1 and some error
message from GRASS GIS (from v.to.rast), it would suggest that caller
module didn't prepared inputs for v.to.rast correctly. In this case, the
caller module would have to prepare the results in a better way, or check
them before calling v.to.rast or wrap v.to.rast call in try-except and deal
with the error somehow. Alternatively, if the v.to.rast error messages in
anticipated cases would be informative enough for end user to run the
caller module in the right way, it is possible to request start_command
family functions to fail with fatal error.

If this makes sense to you, I should put this to the manual, but not today.

Vaclav

> Thanks,
> Markus
>
>
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20150404/5bbb422e/attachment.html>