On Sat, Apr 19, 2014 at 12:43 AM, Glynn Clements <[email protected]> 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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
