[GRASS-dev] grass is a monad?

[Glynn Clements]

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