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

[Eric G. Miller]

On Tue, Oct 22, 2002 at 10:48:13PM +0100, Glynn Clements 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 ;)

> 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.

Well, here we don't disagree.

> 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...

> 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...

Then we can talk about tiled rasters....

-- 
static const char signature[] = 
	"Copyright (c) 2002 Eric G. Miller <egm2 at jps.net>";