[GRASS-dev] [GRASS GIS] #2326: Command functions in grass.script.core miss a correct error reporting

GRASS GIS trac at osgeo.org
Sun Oct 5 19:48:03 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 wenzeslaus):

 Replying to [comment:19 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.
 >
 This is a serious change which will require a lot of testing in both
 modules (core and addons) and GUI. What are the opinions on doing
 something like that?

 The alternative is to go for 7.x and probably even further (8.x) with the
 current unsafe but broadly used API which can be used right in most of the
 cases (but not e.g. in case of `read_command()`). We may provide better
 alternatives and propose them when they are ready. We can also do some
 static source code checks (using regexp) which would look for using the
 return values of `run_command()` etc.

 I kind of tend to the conservative alternative since it is less work over
 longer period and I cannot work on the ultimate solution now at least not
 at the level and focus it deserves.

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2326#comment:20>
GRASS GIS <http://grass.osgeo.org>



More information about the grass-dev mailing list