[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