[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