[GRASS-dev] GRASS & QGIS: the future

Glynn Clements glynn at gclements.plus.com
Tue May 27 16:49:16 PDT 2014


Radim Blazek wrote:

> >> > 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?
> >
> > The raster library installs a handler which calls Rast__unopen_all().
> > The vector and DBMI libraries provide interfaces to it, although I
> > don't know how (or if) these are used at present.
> 
> It is desired that Rast__unopen_all() is not called before longjmp(),
> I think. I don't want to close all maps successfully opened before.

It can be removed with

	G_remove_error_handler(Rast__error_handler, NULL);

But I still think that the global error handler is the wrong place for
a longjmp(). Its original purpose was to allow the standard
notification mechanism (stderr, log file, and/or email) to be replaced
with a custom mechanism.

Can you try the attached patch? The new function should be used like:

	if (setjmp(*G_fatal_longjmp(1))) {
	    // this will be executed on fatal errors
	}

-- 
Glynn Clements <glynn at gclements.plus.com>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fatal-longjmp.patch
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140528/cf82b839/attachment.ksh>


More information about the grass-dev mailing list