On Fri, 24 Aug 2007 04:48:39 +0100, Glynn Clements <[EMAIL PROTECTED]> wrote: > > > A catch only helps if you do something useful once you've caught the > exception. > > If the caller is relying upon the procedure to return information, and > the inability to execute the program means that the information cannot > be obtained, then there isn't any practical alternative to allow the > exception to propagate up to the caller. > > Sometimes it may be worthwhile catching an exception just so that you > can re-throw the exception with additional data. But in the case of > exec failing, the specific error (e.g. "unable to load shared library > libfoo.so") needs to be retained.
Yes sorry I wasn't clear = I meant keeping the stderr output as well as catching the error, and then something along the lines of displaying it in a pop-up dialog to the user - if the program just failed then a pop-up dialog would say that but if there was also an informational error message it would be displayed in the pop-up and could be a valuable hint as to the source of the problem. I did a bit of that in the recent changes I made to the way g.proj was run in the background when creating a new location during the gis_set.tcl startup - that's where the idea was coming from. _______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev
