False exceptions?" (was Re: theme of the week: tools

[Richie Hindle]

[Stephan]
> The "false exceptions" thing is a technical limitation of detecting
> whether or not an exception is going to lead to program termination at the
> moment it is raised, rather than later when exiting the program.  We go up
> the stack to inspect Python byte code, and since we can't see into C/C++
> object code we sometimes get it wrong.

Thanks for this explanation - very interesting.  I'm a bit confused as to why
you do this, though.  Assuming an exception "is going to lead to program
termination", trapping it at the point it's raised is only one instruction
away from trapping at the point it causes termination (via sys.excepthook).
When it hits sys.excepthook, it's still carrying all the stack frames that led
to its being thrown.  If you make those stack frames available in the
debugger, you'd still be able to inspect the state of the code as it was when
the exception was raised.  Nothing can have happened to change the state of
the program in the intervening... ah, OK, 'finally' blocks.  'Finally' blocks
will run between the exception being raised and sys.excepthook being called.
Is that really the only reason you've implemented this feature, or am I
missing something?

-- 
Richie Hindle
richie at entrian.com