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

[Stephan Deibel]

Hi,

I'm the dope that co-wrote this thing, so here's the technical background:

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.  We call it a "false positive"
because it's the same as a blood test telling you you've got something
that you don't.

Believe it or not, we were not just being dumb:  We weighed having a
necessarily imperfect but useful feature with not having the feature at
all.  Same as having an imperfect blood test rather than not at all.  In
fact, from feedback, it seems most people agree that ignoring a few
exceptions during the first debug run is worth always being able to
inspect the unaltered program state seen immediately at the moment the
exception is raised (before, e.g., 'finally' clauses are executed).  
That's why it's on by default, but can be turned off in prefs.

Maybe we got that wrong, but I dunno... the people we hear from may not
represent the overall experience.

Dan Perl wrote:
> No, this is NOT a "useful exception related feature", it's a workaround 
> for a bug.

I think I'd have to agree that the paragraph you cited muddles up the
utility of ignoring exceptions with under-explaining the false positives.
The feature is not just there as a workaround but it's probably fair to
say that's 99% of what it's used for.  Sorry about that.

BTW, the 10 day trial can be renewed automatically.  Then if you run out,
just ask for more time.  No problem.  Deciding the duration of trials is a
nasty business decision that's not easy to make.  I can't really make
excuses -- it's just how it is right now.

Stephan Deibel

--
Wingware
Wing IDE for Python
Advancing Software Development

www.wingware.com