Dne 16.5.2014 18:36 "Glynn Clements" <gl...@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 <gl...@gclements.plus.com>
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer