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

[Glynn Clements]

Vaclav Petras wrote:

> > The key feature of G_fatal_error() isn't printing error messages. The
> > key feature is that it doesn't return.
> >
> 
> This is one of the problems of G_fatal_error(), it does not gives good
> error messages to the user. User gets "G_malloc: unable to allocate %lu
> bytes of memory at %s:%d" but does not have any idea when and why this
> happened and what to do about it. If the module calling G_malloc() had the
> chance to report error by itself, it could suggest to user to change some
> parameter or use a smaller map.

It could, but 99% of the time it won't. Instead, it will either assume
that the returned pointer is valid, or provide some vacuous message
such as "out of memory" (without the reference to the source file,
line number or requested size that is given at present).

So in a handful of cases, you'd get a better error message, while the
rest will be even worse. At least the current situation ensures that
there are enough clues that the GRASS developers can provide
assistance to the user upon request.

When I replaced status returns with fatal errors in a number of core
functions (r40209, r40217, r40701), in some of the cases where the
function's return type changed from int to void, not a single error
was generated; IOW, not one of the callers actually bothered to check
whether the call succeeded.

Similarly, in cases where an int/pointer return value could be
negative or null to indicate an error, the cases where the (now
redundant) error tests needed to be removed from the callers were
often a minority, sometimes a very small minority, occasionally zero.

With G_fatal_error(), the requirement for the caller to check for
errors is removed, and with it the possibility that the caller will
either fail to check for errors, or produce an entirely useless error
message (although I think that we've now eliminated all of the
G_fatal_error("oops!") cases; no, I'm not joking).

> G_fatal_error() is too low level not only for messages but in general, for
> Python libraries wrapping GRASS library, it does not allow to throw an
> exception in case of an error. And the same applies for C++ wrappers.

If you want to turn fatal errors into exceptions, the correct way to
do it is to use setjmp/longjmp (and contribute patches to make any
intervening code exception-safe).

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