[GRASS-dev] GRASS & QGIS: the future

[Glynn Clements]

Radim Blazek wrote:

> Unfortunately GRASS 7 moved ahead towards its aim "to make life harder
> for anyone trying to use the GRASS libraries" [1].

That isn't actually the reason why various functions have had status
returns changed to fatal errors. The reason is to avoid pushing the
burden of error handling onto their callers.

> Basically more and more low level functions are calling exit()
> instead of returning error code if something failed. As I am not
> willing to implement GRASS module call for each simple function, we
> have to think again about hacks we can use:
> 
> 1) add a requirement that GRASS 7 used with QGIS must be compiled with
> -fexceptions

By itself, this will do nothing.

> 2) add a requirement that a patch (it is a single line comment in
> fact) must be applied to GRASS 7 to make it usable with QGIS

If you're talking about replacing the exit() with a "return", that
will typically just result in the caller crashing when G_fatal_error()
fails to perform its primary function (prevening any code which
follows it from being executed).

> 3) use setjmp()/longjmp()

That is the sane option.

But bear in mind that subsequently calling any GRASS function is
entirely "at your own risk". A call to G_fatal_error() often means
that internal data structures will contain garbarge.

If you want to submit patches to perform clean-up in the event of
fatal errors, they will presumably be accepted.

Failing that, it may be advisable to have G_fatal_error() zero-out
certain core data structures (e.g. R__) so that people don't make the
mistake of trying to carry on as if nothing happened.

> 4) let QGIS crash whenever GRASS lib function fails

s/crash/terminate/

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