[GRASS-dev] Vect_*_fatal_error()

[Glynn Clements]

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 <glynn at gclements.plus.com>