[GRASS-dev] Re: problem with G_fatal_error

[Benjamin Ducke]

Martin Dobias wrote:

> 
> I think copying the implementation could make it even worse as we
> would need to watch any changes in GRASS implementation of such
> functions. Or did you mean to copy it inside GRASS?

Yes, that's what I was actually thinking about: an additional library
to be bundled with GRASS that provides "non-fatal" versions of the
functions a GUI most likely needs to call and handle.
Let's call it "GUI handler lib".

BUT, instead of duplicating code: make renamed copies of the functions
in question in the same C file that return an int instead of calling
G_fatal_error and replace the current G_open_* etc. with wrappers that
catch the return value, than exit as appropriate.
Then, put another wrapper into the "GUI handler lib" that provides a
non-exiting wrapper to be called by QGIS.

That way, QGIS developers will always be able to rely on the functions
inside "GUI handler lib" to not trigger fatal errors and we don't need
to keep two different files updated. We can keep adding functions  to
the "GUI handler lib" as needed.

> 
> I've fixed the problem using setjmp/longjmp functions as Glynn suggested.

So does that give you any bad side-effects? It sounds rather like a
hack.

Which leads to option 2: create a global variable that controls whether
fatal errors should trigger an exit() or not and make all GRASS C API
functions that potentially call G_fatal_error() respect this.
However, I think this may create a lot of unpredictable behaviour (!?)

Maybe it would be enough to modify G_fatal_error() in that case?

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

That should be a simple grep job ;)

> The problem is that GRASS support for QGIS was in fact Radim's one-man
> project.  Now he's not active in development, so GRASS plugin doesn't
> get enough attention from developers. We would really welcome anyone
> interested in taking care of the GRASS plugin in QGIS.
> 

Yes, I realize that. I am very interested in developing the QGIS GRASS
interface further. My current job does not leave me enough time to do
that. However, next spring I will start a new contract where I can
exclusively focus on OS GIS development more or less full-time.
I am very excited about this and hope I will be able to contribute
more to both GRASS and QGIS then.

For now, we'll have to do with the small resources we have, be patient
and above all work together. The prospect of having a perfectly stable
GRASS kernel running underneath a slick cross-platform desktop GUI is
just too important to lose sight of over design issues.

Best,

Benjamin

-- 
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg