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

David Bolen db3l at fitlinxx.com
Tue Sep 28 12:44:20 EDT 2004


"Dan Perl" <danperl at rogers.com> writes:

> "Marco Aschwanden" <PPNTWIMBXFFC at spammotel.com> wrote in message 
> news:mailman.3996.1096354841.5135.python-list at python.org...
> > On Mon, 27 Sep 2004 12:04:47 -0400, Dan Perl <danperl at rogers.com> wrote:
> >
> > I myself felt disturbed by your comments on WingIDE. But yes, I do 
> > understand your nagging on "false exceptions" which can be turned off. You 
> > turned it down because of this and because the short trial period (which 
> > can be prolonged with 1 button click)... well, it didn't seem fair towards 
> > the tool. It has its shortcomings but the ones you mention are ridiculous.
> 
> The 10 day trial period just gave me a bad first impression and the 
> explanations for the false positives just left me with a bad taste.  I gave 
> up on Wing because of the false positives (their simple existence, even 
> without the explanations) and the lack of a class browser.  I encountered 
> the false positives first and I almost gave up right there.  But it was just 
> the first day and I thought I should look more.  Like you say, I wanted to 
> be fair.  When I found that the class browser is not supported in the 
> Personal edition I threw my arms in the air.

For whatf it's worth, the "false positives" you refer to was a
significant reason that I really liked Wing.

If you ever use any code that runs Python through an extension
boundary (my key use is with wxPython, where all of your GUI objects
and event handlers run from within the wxPython extension), Wing is
one of the few debuggers that catches exceptions in that code.  That's
because normally the exceptions are handled by the wxPython extension
module, and then suppressed so that they don't kill the main event
loop.

In my experience, there are minimal other false positives that a
normal application triggers (a consistent one I recall was in the sre
code), although the current 2.0 beta may still be getting tuned with
respect to its default "known" list, and I was more than willing to
mark those to be ignored in order to be able to be sure of catching
any exceptions within my own code, regardless of whether it was
triggered through an extension or not.

>(...)
> My "nagging" on the false positives is mostly on the spin that Wingware puts 
> in their explanations.  It's one thing to explain it the way that Stephan 
> did, that it was better to offer something imperfect if that was also 
> providing some important advantages and then also offer the other 
> alternative ("We weighed having a necessarily imperfect but useful feature 
> with not having the feature at all.").  And it's another thing to insist 
> that this is not a problem and it is actually good for you.  This doesn't 
> seem to bother other people as much as it bothered me, but I do have a beef 
> with it.

The actually good for you part is arguably true, since otherwise you
have the potential to be generating exceptions in your own code and
not even know it.  But I agree that different people will react
differently (note how differently you and I reacted to this feature),
so the more that can be done to explain the feature (and its
configurability) the better.

-- David



More information about the Python-list mailing list