[GRASS-dev] Vect_*_fatal_error()

[Sören Gebbert]

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 <glynn at gclements.plus.com>:
>
> 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 <glynn at gclements.plus.com>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>