On Sun, Apr 15, 2012 at 08:34, Christopher Sean Morrison <[email protected]> wrote: ... > There are certainly places and situations where a bomb > might not be caught (such as during the 'catch' or outside the try/catch). > Would be helpful to see the stack trace in that case to see > where exactly it was during execution.
Good advice. > There are possibly some outlier situations too like calling > multiple try/catch within a try where an internal exception > might get caught disabling the top-level try/catch. The problem > from an implementation standpoint is that the NMG code is very > bomb-happy and uses it as part of normal processing instead of > error code propagation. The code should be changed to only > bomb on critical memory failures (and not try/catch within itself). That looks like the situation here. >> That is what gets me--it doesn't work. It's like there's a third >> stream which goes to the terminal no matter what. > > There is exactly that for a bomb that is tearing down an application. > Given they're considered a non-normal abort (basically a graceful > crash), every attempt is made to let the user know what happened which > includes printing directly to /dev/tty (which cannot be captured). Aha! > Note that only happens when 1) there is no log handler and 2) there is no > jump (try/catch) set. The application is going down in a (controlled) blaze > of glory. Definitely describes the situations. Thanks, Sean. Best, -Tom ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
