[GRASS-dev] Re: problem with G_fatal_error

[Martin Dobias]

On 10/22/07, Glynn Clements <glynn at gclements.plus.com> 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.
>
> Code which calls G_fatal_error() is entitled to assume (and normally
> does assume) that G_fatal_error() will not return.
>
> If you don't want G_fatal_error() to terminate the process, you need
> to ensure that your fatal error handler doesn't return, but e.g.
> longjmp()s back to your code.

Hi Glynn,

don't you think it's very inconvenient for users of GRASS libraries
that stable API changes its semantics? And isn't that weird that a
library function calls exit() to close the process it is using it?

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

I'll take a look at longjmp()

Martin