[GRASS-dev] GRASS & QGIS: the future

[Radim Blazek]

On Sat, Apr 19, 2014 at 12:43 AM, Glynn Clements
<glynn at gclements.plus.com> wrote:
>> 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.

I mean to allow to throw exception from the function set by
G_set_error_routine().

>> 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).

Right, nonsense.

>> 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.

Good.

> 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.

Do you mean to add some Rast_clean() to GRASS lib and call it from
G_fatal_error()? Something to be done in GRASS library?

Still, any dynamically allocated memory, to which there is no pointer
from static structures like R__, will never be released.

Radim