[GRASS-dev] [GRASS GIS] #2326: Command functions in grass.script.core miss a correct error reporting
GRASS GIS
trac at osgeo.org
Sat Jul 5 15:08:45 PDT 2014
#2326: Command functions in grass.script.core miss a correct error reporting
--------------------------------+-------------------------------------------
Reporter: wenzeslaus | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: major | Milestone: 7.1.0
Component: Python | Version: svn-trunk
Keywords: script, exceptions | Platform: All
Cpu: Unspecified |
--------------------------------+-------------------------------------------
Comment(by glynn):
Replying to [comment:18 wenzeslaus]:
> What do you (all) think about moving the function `call_module()` from
testing framework into the `grass.script.core` module?
My concern is that people might use it when the existing commands (once
the error handling is fixed) would be more appropriate.
> The main point of this function is that it raises exception when return
code of the module is non-zero.
The existing commands should be changed to do that.
> Additionally, it provides an convenient interface for capturing stdout
and stderr and also for (optional) providing stdin (as string, or stream).
It uses the safest possible way to achieve this which is
`Popen.communicate()` method.
>
> By default it captures stdout (stdout=PIPE) and returns it as string
This shouldn't be the default. The default should be to inherit the
script's stdout. And if capturing stdout is the only feature required
(compared to run_command), read_command should be used.
> and captures stderr (stderr=PIPE) and puts it into the exception when
return code was non-zero.
This should never be done for normal scripts. Child process should inherit
the script's stderr.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2326#comment:19>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list