Hi, i respect the G_fatal_error() design decision and i think it is a very good decision for a C based library which should be used to implement processing modules. What puzzles me is, that interactive vector digitizing is IMHO hard to implement using this design decision. I think that was the reason that many functions of the vector library have return values rather than calling G_fatal_error().
As Glynn stated you will face unexpected behavior when forcing G_fatal_error() not exiting, because of the not existing memory management/error handling in the library design after a G_fatal_error() call. IMHO one solution is to keep editing functions in the vector library G_fatal_error() free, implementing a robust error handling and memory management for such functions. Higher level functions which should be used in processing modules should implement the G_fatal_error() behavior. The core vector/gis library functions should still use G_fatal_error(). The next point is to have a separate vector digitizing process for the wxGUI digitizer. How should this work? Using RPC to have access to the vector library in wx C++ code? Implementing special editing modules ... which make vector editing IMHO very slow? Best regards Soeren 2011/11/12 Glynn Clements <[email protected]>: > > Martin Landa wrote: > >> it continues with all wxGUI components which are using GRASS > libraries via ctypes. > > The number of such components should be zero. > >> Just try to use vector digitizer >> or wxNViz, the whole GUI just crashes without any kind of message when >> G_fatal_error() is called. > > Yep. The solution has been made clear on multiple occasions: don't > access GRASS libraries from the main GUI process. wxNVIZ in particular > should absolutely be a separate process (OpenGL drivers are not noted > for their stability). > > Even if the exit()-on-fatal-error issue magically disappeared, the > memory management issues (i.e. don't bother tracking allocations which > don't matter for a typical module) won't. Nor will the fact that > "try ... except" won't catch a segfault. > > grass.lib.* exists for "module-style" scripts, not for persistent > applications. > >> Well due to design, anyway very user >> friendly. I am not a fan of G_set_fatal_error() solution, on the other >> hand I don't see any reason why to *forbid* so strictly the >> programmers which are using GRASS libraries to avoid calling system >> exit on G_fatal_error(). The default behaviour will remain! We just >> let other programmers (with a big warning) to use GRASS libraries for >> the purpose which they were not originally designed nothing more. > > Allowing G_fatal_error() to return isn't going to stop wxGUI, QGIS, > etc terminating unexpectedly. It's just going to make them terminate > via a segfault rather than via exit(). > > If a function calls G_fatal_error(), it isn't expecting it to return. > If it does return, the usual result will be that the caller attempts > to use invalid data; a crash isn't likely to be far off. > > A typical example of G_fatal_error() usage is: > > FILE *fp = fopen(...); > if (!fp) > G_fatal_error(...); > fread(..., fp); > > Allowing G_fatal_error() to return will simply replace the exit() with > a segfault. Why would this be an improvement? > > If you want to (attempt to) recover from fatal errors, you have to > escape from G_fatal_error() via a longjmp(). Either that, or you have > to re-write every single use of G_fatal_error() (~3800 of them) to > accomodate the possibility of it returning. > > Except that the latter isn't really an acceptable solution, as it > pushes the burden of error handling on to everything else. You might > consider making your job easier justifies making everyone else's > harder, but don't expect everyone else to agree. > > So long as I have commit privileges, G_fatal_error() is going to > retain (and honour) the "noreturn" attribute. > > Aside: In 7.0, I changed a number of library functions which had > previously returned a status code to call G_fatal_error() instead. > This meant eliminating the status-checking from the callers, as the > return type changed from "int" to "void". > > Which lead me to discover that, for modules, actually bothering to > check the status code tended to be the exception rather than the rule. > IOW, even with most functions using G_fatal_error() to eliminate the > need to check status codes, the burden of dealing with the few which > didn't was still too much. > > -- > Glynn Clements <[email protected]> > _______________________________________________ > grass-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-dev > _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
