[GRASS-dev] [GRASS-SVN] r60054

[Glynn Clements]

Huidae Cho wrote:

> Simply calling fatal error and terminating the process may not be a good
> idea in some case where  many leftover files need to be deleted. I believe
> at some point we need to standardize error handling.

I feel that exit handlers (or similar) are the way to go here. We
might want our own mechanism rather than using atexit(), so that it
works even when longjmp()ing out of a fatal error handler.

Apart from the global error handler (G_set_error_routine), we probably
want to support multiple, non-exclusive handlers.

[We may also want to support the ability to push/pop the global error
handler so that it's possible to perform the equivalent of catching an
exception then re-throwing it. But this needs feedback from anyone who
happens to be using it (its only within GRASS is by 3 curses-based
imagery modules, all of which are disabled, to restore the terminal).]

For temporary files, I suggest adding a "mode" argument to the
creation function to indicate whether the file should be:

* deleted automatically upon fatal error
* deleted automatically upon exit, successful or not
* deleted (unlink()ed) immediately (on Unix) or on exit (Windows).
* retained until explicitly deleted.

Building this behaviour into the libraries rather than having the
caller do it provides consistency. It also allows e.g. having an
environment variable to suppress deletion of temporary files for
debugging purposes.

> But still I agree that we need a better way to handle opening
> errors.

I don't feel that it's worth attempting to recover from such errors,
in the sense of continuing with normal execution. Clean up, then
terminate.

Users shouldn't specify non-existent or otherwise invalid maps as
arguments, and shouldn't expect anything beyond an error message if
they do.

If there are specific cases where a map's existence shouldn't be taken
for granted (e.g. the name was obtained from metadata which might be
stale or otherwise inapplicable), we should use G_find_* before
attempting to open it.

-- 
Glynn Clements <glynn at gclements.plus.com>