[GRASS-dev] GRASS & QGIS: the future

[Radim Blazek]

Dne 16.5.2014 18:36 "Glynn Clements" <glynn at gclements.plus.com> napsal(a):
>
>
> Radim Blazek wrote:
>
> > There is a problem in G_fatal_error():
> >
> >     static int busy
> >     if (busy)
> >         exit(EXIT_FAILURE);
> >     busy = 1;
> >
> > second G_fatal_error() call always exits.
> >
> > The busy check is there for the case when print error routine itself
> > ends up with call to G_fatal_error()?
>
> It's there to prevent infinite recursion, whether from the printing
> code, a fatal error handler, or whatever.
>
> > May be the busy variable made global and added a function to clear it?
>
> That might be going a bit too far. OTOH, it can't be cleared prior to
> calling the handler because it's intended to protect against the case
> of a handler generating a fatal error.

I ment some G_fatal_error_recover() which would be called as last thing
from QGIS error routine.

> One possibility would be to add explicit support for longjmp()ing out,
> e.g. adding G_error_longjmp(jmp_buf env, int val) which would clear
> the busy flag then perform the longjmp. That would avoid exposing the
> internals more than is necessary.

Sounds good.

> Also, currently the global error handler (G_set_error_routine) is
> called before the non-exclusive handlers (G_add_error_handler), so
> those will never be called if the global handler lonjmp()s out. The
> global error handler isn't limited to fatal errors, but is also used
> for messages and warnings.

G_add_error_handler() is used by GRASS itself?

> Perhaps we need a dedicated fatal error handler for this purpose? It
> would be called immediately prior to the final exit() call. It would
> not be allowed to call GRASS functions or to return. The busy flag
> could be cleared before calling it.

Whatever allows to "recover" from fatal error will help. I would prefer
however not changing semantics too much so that GRASS 6, 7.0.0beta1 and
7.x.x may be easily supported by the same code with only few ifdefs.

Radim

>
> --
> Glynn Clements <glynn at gclements.plus.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140517/ebe257c8/attachment.html>