Martin Dobias wrote: > > > Even better would be to make a list of GRASS functions which could end > > > with fatal error. Now it's fixed only for that particular know case > > > where it was terminating QGIS, but I guess there might be more such > > > functions... > > > > The list would be most of GRASS. > > > > E.g. G_malloc() calls G_fatal_error() if malloc() fails (although you > > probably can't handle that case anyhow). Anything which uses the > > environment (database, location, mapset, etc) will fail if $GISRC > > isn't set, can't be opened, doesn't contain correct data, etc. > > > > It might (literally) be simpler to list functions which can't call > > G_fatal_error(). > > Ah, so in that case we should use setjmp() before (nearly) every call > to GRASS routine, which is not a way to go. Thus I think we'll stick > with using setjmp() explicitly only at places known to produce fatal > errors. Or are there some more possibilities?
Well, you would normally call setjmp() at the beginning of a user-level "command", and just abandon the entire command if anything fails. E.g. in a GUI, you might call setjmp() from the event loop, so a corresponding longjmp() would abandon further processing of that event and move on to the next. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
