On Sat, Apr 4, 2015 at 9:14 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Apr 5, 2015 3:07 AM, “Anna Petrášová” <kratochanna@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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
