[GRASS-dev] Re: problem with G_fatal_error

[Benjamin Ducke]

Glynn Clements wrote:
> Martin Dobias wrote:
> 
>>>>> The problem looks like this: QGIS calls Vect_open_old_head function -
>>>>> that one finds out that the layer is corrupted and calls G_fatal_error
>>>>> routine. Looking at that function I see that in 6.3.cvs the function
>>>>> always calls exit() which is incorrect, because this takes also the
>>>>> whole QGIS down. GRASS 6.2 has a condition "if ( ext_error ) return
>>>>> 0;" before the exit statement, so since QGIS sets extended error
>>>>> handler, everything is okay. Please could you add that condition back?
>>> No.

Maybe this one particular case could be patched up by making a copy of
GRASS' Vect_open_old_head function (like Vect_open_old_head_no_exit) and
using that to interface from QGIS?
I would expect that if there are more problems of that type, they should
all appear in calls of "open_something" or "close_someting" and maybe
some basic data retrieval functions, as the
QGIS interface probably doesn't need much more than these in order to
interface with GRASS and display GRASS maps?

Would it be possible to make a list of all GRASS lib functions that
QGIS calls directly, then look through them and make modified copies
of everyone that needs a different error handler (maybe putting them
altogether into a "GRASS_gui_handler" lib or sth. like that)?

> 
> It needs to be borne in mind that the GRASS libraries were (and are)
> designed for GRASS, which is a collection of "one-shot" programs (i.e. 
> you run the program with arguments, it does its work, then exits). The
> design of the libraries is fundamentally unsuitable for persistent
> programs.
> 
> If you feel like re-writing the whole of GRASS to propagate all errors
> up to the individual programs and handle them there (and cleaning up
> any inconsistent state along the way), I'm sure that the effort will
> be appreciated.

GRASS has earned our appreciation as a GUI-independent GIS toolbox, but
the fact remains that a GUI-integrated approach such as QGIS will open
it up to a multitude of new users and we need to support this in my
opinion.
Of course, GRASS' stability throughout the years has much relied on
the clean, Unix-based design that especially Glynn has been keeping
in a consistent state, but I am sure we can find bridges here.

> 
>> Btw. thinking about such incompatible changes, is there any resource
>> on internet or low-traffic mailing list which would announce any such
>> changes? Because this is not the first time that something got
>> changed... :-/
> 
> The only resource which documents every bug-fix is the grass-commit
> list, and that certainly isn't low-traffic. Even if we had an
> -announce list, there's no reason to suspect that this particular
> change would have been announced there; it isn't as if anyone would
> have known that you were relying upon this particular detail.

Probably all true from a technical point of view but I sense that
there is some frustration building up among QGIS developers about
constantly having to catch-up with the results of the very
"different" nature and philosophy of GRASS development. We need
a stronger cooperation between both development teams to concentrate
on a Win32 GRASS "kernel" that can go into regular QGIS releases.

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