[GRASS-dev] Re: problem with G_fatal_error

[Glynn Clements]

Martin Dobias wrote:

> > > Even better would be to make a list of GRASS functions which could end
> > > with fatal error. Now it's fixed only for that particular know case
> > > where it was terminating QGIS, but I guess there might be more such
> > > functions...
> >
> > The list would be most of GRASS.
> >
> > E.g. G_malloc() calls G_fatal_error() if malloc() fails (although you
> > probably can't handle that case anyhow). Anything which uses the
> > environment (database, location, mapset, etc) will fail if $GISRC
> > isn't set, can't be opened, doesn't contain correct data, etc.
> >
> > It might (literally) be simpler to list functions which can't call
> > G_fatal_error().
> 
> Ah, so in that case we should use setjmp() before (nearly) every call
> to GRASS routine, which is not a way to go. Thus I think we'll stick
> with using setjmp() explicitly only at places known to produce fatal
> errors. Or are there some more possibilities?

Well, you would normally call setjmp() at the beginning of a
user-level "command", and just abandon the entire command if anything
fails.

E.g. in a GUI, you might call setjmp() from the event loop, so a
corresponding longjmp() would abandon further processing of that event
and move on to the next.

-- 
Glynn Clements <glynn at gclements.plus.com>