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

[Glynn Clements]

Eric G. Miller wrote:

> > > 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.
> 
> I thought one of the reasons we wanted abort()/exit() type function
> calls removed from library functions is that they really interfere
> with any future possibility of using libgis, et al. in long lived
> programs (like GUI's).  I'm fairly certain I didn't invent the idea ;)

OK. G_fatal_error() doesn't have to terminate the program; perhaps we
should use something with a different name. It's fatal in the sense
that it doesn't return to the caller.

I do see the point regarding long-lived programs. Real exceptions
would be nice, but we ought to be able to provide an adequate
simulation with a stack of error handlers and setjmp/longmp.

Or have G_maybe_fatal_error() for library functions. The code would be
written to allow for this function returning, but it would actually
call G_fatal_error() unless the program had called e.g. 
G_disable_fatal_errors(). IOW, programs which explicitly ask for
status returns get them, otherwise errors are "fatal".

I still think that ACID commit/rollback would be a good idea. It
wouldn't be massively hard to implement, assuming that we're dealing
with whole maps (i.e. you can't have one user updating the cell data
while another is updating the colour table).

> > 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.
> 
> Yes, just G_open_<thing>(const char *path) returns <thing>_t, and if
> the function can't find it, well that's the way it goes.  Unfortunately,
> all modules are too close to the implementation details...

However, much of it is boilerplate; AFAICT, most modules only deal
with mapsets because the API forces them to.

> > 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()).
> 
> Well, I never liked the <name>@<mapset> thing.  I don't think it worked
> out as well as its designers envisoned.  I'd still rather see:
> 
> <mapset>/<thing>/<name>/
> 
> with all the stuff for the "thing" named "name" under the "name"
> directory.  Then again, possibly even get rid of "thing" and just
> discern the type of "thing" by the contents of the directory...
> Anyway, I think it should map to the filesystem in a easily
> understood manner for the user...

The main issue with the "thing" part is whether we think that being
able to have both a vector map and a raster map with the same name is
a good idea or not. Personally, I think not.

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