[GRASS-dev] Re: problem with G_fatal_error

[Martin Dobias]

On 10/25/07, Benjamin Ducke <benjamin.ducke at ufg.uni-kiel.de> wrote:
>
>
> 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.

That sounds reasonably, I guess that also other 3rd party tools which
use GRASS would appreciate this.

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

I think if one takes care, there are no bad side effects. However
using setjmp and longjmp generally makes the code harder to understand
as it changes usual execution. In C++ you must be even more careful
about the jumps because longjmp skips destructors of C++ classes
created on stack, so this may lead to some bad behaviour.


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

No idea about this. However until now (versions < 6.3) when there was
custom error routine, G_fatal_error didn't call exit() and everything
was fine (at least it seemed so).


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

That would be great!

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

True, true :)

Martin