On Apr 15, 2012, at 6:53 AM, Tom Browder wrote:
> Well, g-nff does have a handler ("try/catch") but the failure (a bad
> tree struct after the boolean functon) isn't being handled. I'll check
> the others Ilisted, to see if it's the same problem.
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.
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 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).
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.
Cheers!
Sean
------------------------------------------------------------------------------
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
