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 <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
