[GRASS-dev] [bug #4522] (grass) r.series: error in row of input map is non-fatal giving wrong results

Glynn Clements glynn at gclements.plus.com
Wed May 31 13:11:17 EDT 2006


Hamish wrote:

> > > The read error should trigger a G_fatal_error().
> > 
> > Agreed. The question is: why does libgis leave this to individual
> > modules rather than doing it itself? Are there really modules which
> > might want to do something other than call G_fatal_error() in this
> > case?
> 
> I doubt it.
> 
> Is there a possibility of many orphaned .tmp files if the module exits
> during a read while an output map open?

Yes.

> i.e. how important is it to exit
> with clean-up at any given point of a typical raster [read; do stuff;
> write] operation?

Almost nothing does this at present. Even modules which check the
return value from G_get_raster_row() etc usually just call
G_fatal_error() if it fails.

There are precisely 20 files in 15 modules which call G_unopen_cell(),
while there are rather more than that which create new raster maps. 
The remainder simply don't bother to clean up upon errors (including
r.example).

I suggest that:

a) G_get_raster_row() etc should automatically call G_fatal_error() if
an error occurs, with a function to disable this behaviour for modules
which really need to do their own error handling.

b) It should be the library's responsibility to clean up incomplete
maps upon exit.

Having to manually check for error conditions and perform clean-up
whenever an error occurs is enough of a nuisance that it will
frequently be omitted (or, if error handling is added, those code
paths will seldom get tested and thus will frequently contain bugs).

-- 
Glynn Clements <glynn at gclements.plus.com>




More information about the grass-dev mailing list