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

GRASS GIS trac at osgeo.org
Mon Oct 6 08:59:16 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 zarch):

 Replying to [comment:22 wenzeslaus]:
 > Replying to [comment:21 zarch]:
 > >
 > > So are 255 lines that need to be checked and adapted. 46 lines in
 > > gunittest, 85 in the temporal framework and 80 in wxpython.
 >
 > I did different search in comment:5 with different results.
 > The problem is that both the ones which are using return code
 > and which are not must be checked.

 I don't agree on this point. :-) So I try to explain better my point.

 All the code that don't check the returncode is a bug, or at least is
 based on a buggy assumption that everything is going fine. If the
 assumption for whatever reason is not honored we will have unpredictable
 results.

 So just continue to use this buggy assumption and focus only where the
 return code is handled, that will change from:

 {{{
 returncode = dosomething(*a, **kw)
 if returncode:
     # do something else
 }}}

 in

 {{{
 try:
     dosomething(*a, **kw)
 except CalledModuleError:
     # do something else
 }}}

 Then when our assumption will be not respect we will have a nice Exception
 that tell us exactly what is failed and where, and then we know that we
 should add a try/except check on this part of the code.

 In this way we can start modifying only a sub-set, that should not take
 too much time, and the code it will not more buggy than how it is now.
 After that we can release, and then star improving all the remaining parts
 of the code.

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



More information about the grass-dev mailing list