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 <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
