[GRASS-dev] [Qgis-developer] GRASS & QGIS: the future

[Glynn Clements]

Martin Landa wrote:

> > Returning from G_fatal_error() won't leave GRASS libraries in an
> > unpredictable state. It's "escaping" from G_fatal_error() via e.g.
> > Returning from G_fatal_error() will typically result in a
> > (more-or-less immediate) segfault when the caller tries to use data
> > structures which contain garbage (because the callee never initialised
> > them, but raised a fatal error instead).
> 
> Well, and what do you think that I meant by "unpredictable state"?

I assumed that you meant the same thing that I do when I point out
that longjmp()ing out of a fatal error handling will leave the
libraries' data in an unpredictable state, i.e. that a *subsequent*
call to a GRASS library function may result in a crash.

Having G_fatal_error() return will usually cause an immediate crash,
without needed any subsequent calls.

> > The simplest example is G__malloc():

> You chose very specific case of course.

I chose the simplest example.

But the more general case is:

1. Code performs a task which can either fail or succeed.

2a. On success, some form of result is stored in one or more
variables.

2b. On failure, the code calls G_fatal_error().

3. The code uses the values of the variables assigned in 2a, taking it
for granted that they contain valid values (because if 1 had failed,
the G_fatal_error() call in 2b ensures that we wouldn't be here).

If G_fatal_error() can return, practically any function which calls it
will either attempt to use garbage data, or will (silently) return
garbage data to its caller.

> There is probably something
> you don't want to understand. In the core libraries (gis, vector,
> raster, imagery) there are 553(!) places where G_fatal_error() is
> called. Some time ago you introduced G_fatal_error() even to the
> function which tries to open raster map [1]. So if the raster map
> doesn't exists the function is calling exit()! This is something which
> makes life harder for anyone who want to use GRASS libraries (as you
> already mentioned) with one exception - modules - standalone programs,

Modules aren't an exception, they're the rule. People wanting to use
GRASS libraries in a persistent application are the exception.

It's the latter category that's doing the "not understanding". 
Specifically, they don't understand the magnitude of the cost involved
in propagating errors all the way to the top-most level using status
returns at each step.

This cost is why modern languages have exceptions. Unfortunately:

1. C doesn't have exceptions. The closest thing it has is
setjmp/longjmp.

2. Exceptions eliminate much of the cost, but not all of it. You still
have to write exception-safe code. But the difference is significant
enough that I wouldn't object to the (comparatively minor) added
complexity resulting from making code exception-safe. Apart from
anything else, the added complexity would be limited to the
implementation of library functions; it doesn't impose a unreasonable
burden on the callers in the way that using status returns does.

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