[GRASS5] G_fatal_error question

[Roger Bivand]

On Sat, 17 Jun 2000, Andreas Lange wrote:

> Hi Markus, hi Roger,
> 
> the general problem is (as i understand), that the GRASS concept assumes
> that every call to the gis libraries comes from a module, that should
> exit() if something goes wrong. The clean way would be to have a
> centralized error handling routine that sets a global error flag and
> returns an error status. But that is nearly impossible to implement now. 

Yes, the essence of the problem is that the library (gis) assumes that
death is a safe solution, and does not consider situations where functions
may be called from "foreign" programs not needing to be killed without
mercy.

The G_set_error_routine() function does work when G_fatal_error and
G_warning are called properly, that is that they are used instead of just
saying exit. Most of what's needed seems to be in place, and having
checked *.[ch] in libes/gis, the critical weaknesses were in error.c,
env.c, and get_row.c, all of which hit exit without going through the
error handler pointed to by G_set_error_routine. Having sorted out that,
the next issue was why it still didn't work - G_gisinit hit a fatal error
with no LOCATION, called G_fatal_error, which called print_error, which
then called log_error (setting active to 1 to avoid recursion), which
couldn't fing GISBASE, calling G_fatal_error again, but not then checking
to see if there is an alternative error handler. I've put edited versions
of the files on:

ftp://reclus.nhh.no/pub/misc/libes.gis.tar.gz

(I don't know that they don't break anything else!!)

> 
> I must admit that i do not know in which way the interfacing between R
> and GRASS is done, so that i have no idea how to circumvent the
> exit()-problem. Possible: spawning a sub-process from R, so that the
> sub-process exits and returns an error. Or setting up an own exit
> handler with atexit().
> 
> Please correct me if i am wrong in assuming that the problem are calls
> to G_fatal_error() from inside the library. Perhaps you could give me an
> example where to look at some code.
> 

The original interface was based on running R in the GRASS environment,
then running GRASS modules as system("g.whatever") from the R prompt, and
collecting the results. There were side effects, overhead for ASCII
transfer and loss of precision. I'm now doing a compiled interface,
dynamically loading a small number of C functions linked against libgis.a
(so far, more libes later). Dynamically loading something that can kill R
- which keeps everything in memory, and saving a big memory image to disk
every time an interface function is called seems a bit unfortunate. That
means that all the GRASS functions I link against need checking to see
that they don't just exit, but use G_fatal_error or G_warning properly. As
far as I am concerned:

G_fatal_error("whatever");
exit(-1);

is OK, because the program will never reach the exit - there are plenty of
cases like this.

Is this vaguely clear? (I'm not too sure myself!) My handler (by the way)
is:

int R_handler(char *message, int fatal) {
		if(fatal == 1) error(message);
			else warning(message);
}

where error() and warning() are R error handling functions that do all of
the housekeeping to get back up the call stack out of the function in
error. As of this evening, it works after having changed the files
mentioned above.

I'd be grateful for any advice.

Best wishes,

Roger

-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand at nhh.no
and: Department of Geography and Regional Development, University of
Gdansk, al. Mar. J. Pilsudskiego 46, PL-81 378 Gdynia, Poland.


---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'