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

[Vaclav Petras]

On Fri, Apr 18, 2014 at 6:59 PM, Glynn Clements <glynn at gclements.plus.com>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. With G_fatal_error() user has only the
possibility to try to guess from debug messages, ask on mailing list or
keep trying with random changes in input parameters. I don't believe that
this is efficient.

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.

As far as I understand, the RPC wrapper suggested earlier by Soeren, would
hopefully allow to have exceptions (and no exit()) in Python and C++ and
thus potentially higher level error messages and also general error
handling would be possible (for those not using the original library).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140418/dcf9dbdb/attachment-0001.html>