[GRASS-dev] Vect_*_fatal_error()

[Glynn Clements]

Martin Landa wrote:

> > If a function calls G_fatal_error(), it isn't expecting it to return.
> > If it does return, the usual result will be that the caller attempts
> > to use invalid data; a crash isn't likely to be far off.
> >
> > A typical example of G_fatal_error() usage is:
> >
> >        FILE *fp = fopen(...);
> >        if (!fp)
> >            G_fatal_error(...);
> >        fread(..., fp);
> >
> > Allowing G_fatal_error() to return will simply replace the exit() with
> > a segfault. Why would this be an improvement?
> 
> The improvement is that you can show at least some error message and
> to quit application with knowing user that the fatal error appeared,
> where appeared, etc. In the most cases it will be bug in the
> application, at least the application will just not crash without any
> message.

Do you actually not understand the problem here? The above example
will segfault immediately after G_fatal_error() returns.

G_fatal_error() does two things:

1. Prints an error message.
2. Prevents execution of subsequent code.

Of these, #2 is the important property; #1 is secondary.

When code calls G_fatal_error(), it isn't simply asking for a
diagnostic to be printed. Far more importantly, it both expects it to
abort execution of the current function (like a "return" statement),
and also to alleviate it of the responsibility for informing the
caller that it hasn't succeeded.

If we were using C++, the solution would be to raise an exception. If
the code wants to handle errors, it can catch the exception, otherwise
it can let it propagate up until either something does catch it or it
terminates the process.

But we aren't using C++, and that isn't likely to change. Apart from a
significant increase in compilation times, C++ is a far more complex
language than C, which is likely to be a problem when some of the
GRASS developers barely understand C.

The closest thing that C has to exceptions is longjmp() (which is
actually how exceptions were implemented on the earliest C++
compilers).

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