[GRASS5] gis lib: write error function (put_row.c)

[Glynn Clements]

Eric G. Miller wrote:

> > > while having the problem that a disk run out of space
> > > while using r.in.gdal, I found that
> > > 
> > > write_error()
> > > in src/libes/gis/put_row.c
> > > just contains G_warning() and not G_fatal_error().
> > > 
> > > Are there objections to change this to 
> > > G_fatal_error("...unable to write row...")
> > > ?
> > > 
> > > It doesn't make much sense to continue writing to a full disk.
> > 
> > Writes could theoretically fail for reasons other than a full disk,
> > although I can't actually think of anything which would be
> > recoverable.
> > 
> > If you change write_error() to call G_fatal_error(), I suggest
> > changing the calling functions to return "void" rather than a status
> > value. That way, if anything was actually checking the return value
> > and attempting recovery, you'll get compilation errors alerting you to
> > the fact.
> > 
> > In all probability, it should just call G_fatal_error(). If there are
> > specific cases which actually want to handle the error, they can use
> > G_set_error_routine().
> > 
> > More generally, library functions which only rarely fail should just
> > call G_fatal_error() IMHO, rather than returning an error status and
> > thereby passing the responsibility to the individual modules.
> 
> If you change G_put_raster_row(), et al. to return void, then it isn't
> very easy to tell where the error came from.

But how much code actually cares? How many programs actually check the
return value of G_put_raster_row() etc? And, of those, how many do
something other than just call G_fatal_error()?

Unless a significant number of programs actually check the status and
do something other than call G_fatal_error(), the library function may
as well call G_fatal_error() itself.

> I thought folks wanted to get G_fatal_error() out of library
> functions...

Which folks? Not me.

Either the library function handles the error itself, or a hundred
individual modules all have to handle the error. The former seems
preferable to me.

More generally, I'd like to push as much of the work as possible down
into the libraries, to make the coding of modules as simple as
possible.

In a similar vein, I'd like to be able to get rid of all of the
explicit calls to G_find_file(), and the need to pass the mapset
around separately. The vast majority of modules should be able to just
pass an abstract map name around; only the libraries would care
whether it was relative or fully qualified.

The main issue there is that we would have to either:

a) change the format of qualified map names to "big-endian", e.g. 
"mapset/map" rather than "map at mapset", so that appending suffices to a
map name works correctly, or

b) provide a function for generating derived map names, and ensure
that modules used that rather than e.g. strcat().

Unfortunately, a) screws backward compatibility, while b) is error
prone (i.e. it requires that programmers actually use the defined
interface rather than strcat()).

Moving functionality down into the libraries not only simplifies
coding, but it can provide possibilities to extend the semantics
without having to rewrite lots of individual modules.

-- 
Glynn Clements <glynn.clements at virgin.net>