[GRASS-dev] GRASS & QGIS: the future

[Glynn Clements]

Radim Blazek wrote:

> >> 1) add a requirement that GRASS 7 used with QGIS must be compiled with
> >> -fexceptions
> >
> > By itself, this will do nothing.
> 
> I mean to allow to throw exception from the function set by
> G_set_error_routine().

Does using a C++ exception have any advantage over longjmp()?

> > Failing that, it may be advisable to have G_fatal_error() zero-out
> > certain core data structures (e.g. R__) so that people don't make the
> > mistake of trying to carry on as if nothing happened.
> 
> Do you mean to add some Rast_clean() to GRASS lib and call it from
> G_fatal_error()? Something to be done in GRASS library?

Well, that was purely off the top of my head. But something like
zeroing the "env" structures in lib/gis/env.c and unsetenv("GISRC").

If it isn't going to work, it should at least fail in an obvious
manner. Rather than e.g. appearing to work for the next hour then
failing when the user decides to (try to) save their work.

Making it actually work would involve tracking down all of the
G_fatal_error() calls in the core libraries and modifying the code to
be "exception-safe".

It isn't something which could be localised to a single "reset"
function for each library. At least, not without moving all static
variables into a single "state" structure. Although, GRASS 7 is
cleaner in this regard; individual subsystems now tend to have state
structures so that initialise-on-first-use is (hopefully) thread-safe.

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