Radim Blazek wrote: > > Also, what kind of fatal errors can occur while in the middle of > > vector editing that could reasonably be recovered from? > > Probably I don't understand the question, for any error I would prefer > to give a decent message > (in window box) and stop editing (even with corrupted vector) but > don't crash the application.
The GRASS way to achieve this is to make the editor a separate process. > > I'm not particularly averse to libraries using status returns, so long > > as this doesn't: > > > > 1. propagate up to the API used by modules, > > So you would suggest a separate set of functions for modules and QGIS/vdigit? Actually, I would suggest QGIS/vdigit isolating actions within a child process, rather than complicating the rest of GRASS for the sake of two programs, one of which isn't part of GRASS and the other was designed incorrectly from the outset. But if there are reasons for specific functions to have status returns, then I would suggest also having a wrapper which signals a fatal error. Doing this wholesale would make too much of a mess, though. > > 2. "infest" a large portion of the GRASS libraries, or > > 3. mean that fatal errors end up being signalled at the highest levels > > after most of the context has been lost. > > What is wrong on calling G_fatal_error on each level from the first > function where the error happened to the top and optionally (i.e. > modules wants exit, qgis/vdigit return value) either only print the > message (call error routine) and return error code or exit (it means > on the lowest level). Exceptions would be nice, but implementing them in C is a mess and re-writing GRASS in C++ isn't an option. Removing the __attribute__((noreturn)) from G_fatal_error() requires a substantial re-write, and isn't an option IMHO. -- Glynn Clements <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
