[GRASS-dev] G_error in Vlib

[Roger Bivand]

On Tue, 6 Jun 2006, Wolf Bergenheim wrote:

> On Tue, 6 Jun 2006, Hamish wrote:
> 
> > Wolf:
> >>>> I need G_error (function that does the same thing as G_fatal_error
> >>>> except that it does not exit). Any objections to me adding it (as
> >>>> soon as I get my CVS working again)? I think it can be good to have
> >>>> a possibility of issuing an error message that doesn't call exit.
> > Glynn:
> >>> That's essentially what G_warning() does.
> >>>
> > Wolf:
> >> Yes but it puts a 'WARNING: '-prefix and not a 'ERROR: '-prefix. (;
> >
> >
> > So what's wrong with "WARNING:" ?   what's the situation?
> >
> 
> It is a fatal error but I can not use G_fatal_error because it calls exit, 
> and I need to properly close the vector in v.edit. One such case is for 
> instance that the DB connection fails. I still need to build the topology 
> or else the vector file is broken (need to run v.build on it before you 
> can continue).

In the orginal GRASS 5 compiled R interface, the error handling is passed 
to R for exactly this reason to avoid exit(). Then it was:

void R_G_init(char *name) {

	G_set_error_routine(R_handler);
	G_sleep_on_error(0);
	G_gisinit(name);
}

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


where R_G_init() simply sets up the handler and the handler lets you set 
the appropriate actions. This of course assumes that your function does 
the clear-up, but G_set_error_routine() certainly worked very nicely in 
the 5.* codebase except where gislib functions called exit() directly - 
this was cleaned later I think by Radim. It is still in current CVS 
lib/gis, so I'd try it first, because it will also grab both GRASS errors 
and warnings thrown by GRASS functions your code calls. 

Roger

> 
> > what about:  G_message("ERROR: zombies");
> >
> 
> Doesn't do the ERROR or WARN magic (like email etc.), and it doesn't beep ;)
> 
> >
> > If it must happen, perhaps it should be called G_nonfatal_error() or
> > something more explicit than G_error()?
> >
> 
> If you have G_error and G_fatal_error and both are documented, then it 
> would be quite clear which does what? But if you like G_nonfatal_error 
> better then I can live with it too. I don't really care that much about 
> the function name, but I do care what it does (;
> 
> --W
> 
> 

-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand at nhh.no