Sören Gebbert wrote: > IMHO the main wxGUI should not make use of library functions which > call G_fata_error() directly, it should use grass modules or start > Python processes which call grass library functions. These processes > can make use of Glynns Python longjmp approach to pass meaningful > error messages to the wxGUI before they get restarted by the wxGUI.
A separate process wouldn't need a longjmp(). Once it has passed the necessary information to the parent, it can just allow the error handler to return and the process to terminate. The downside with RPC mechanisms is that even the most straightforward function call is complicated by the need for error handling. Instead of asking for the value of "2 + 2" and getting 4, you either get 4 or "RPC server not responding, please try again". This can be mitigated to an extent in Python by having a generic wrapper which throws exceptions for RPC failures, so that code isn't cluttered up by having to propagate status indications. The limitation is that recovery may require not only restarting the child process, but restoring its state (e.g. any maps which were open in the old process will need to be re-opened before thay can be referenced). > I learned and have changed my mind. Because the fundamental design of > GRASS and therefor all implemented modules depend on the exit() on > fatal error design decision. It will be almost impossible to change > this if you don't want to rewrite most of the code. Actually, they depend upon the "noreturn" feature. It doesn't strictly have to be exit(), but non-returning functions are in fairly short supply. exit() is one; longjmp() is another, but it has to get a jmp_buf from somewhere. -- Glynn Clements <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
