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

[Dan Perl]

"David Bolen" <db3l at fitlinxx.com> wrote in message 
news:uekkmibrv.fsf at fitlinxx.com...
> "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.

I'm new to wxPython so I cannot relate yet to what you are saying.  The 
wxPython extension module may catch the exceptions and suppress them, but 
doesn't it generate a message for that or something?  I hope that they are 
not hiding the exception completely (and that they generate something) and 
then you can still debug the problem with well placed breakpoints.  Am I 
wrong here or is there something I'm missing?

> 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.

The false positive that I encountered was indeed in 'sre', invoked by 
pickle.  I think it was an IndexError which should be a normal thing if they 
are using it to stop at the end of an iteration.  So I'm not convinced this 
would constitute "minimal" false positives.

Maybe if I would have been convinced first with a personal experience about 
the advantages of Wing's exception detection at the point of raise, then I 
would have accepted the false positives more easily.  But seeing the false 
exception first (actually right away and with positive spins on it) and then 
finding out the right technical explanation later, it made it much harder to 
swallow.

Here is my suggestion to Wingware.  Make the "Never Stop" exception 
reporting mode the default in the Personal edition or at least for the trial 
download.  A tutorial could then lead to the "Stop on Unhandled" mode.

>>(...)
>> 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.

I would need to first see an example of generating an exception without 
knowing it and that exception still being relevant although it is being 
handled.  I can imagine something not working right and an exception being 
one more indication for the problem, but then there are still other good 
ways to debug the problem.  And if things are working, I don't see how 
hidden exceptions may be of interest.  I have very little experience with 
GUIs but I realize that unit testing is much more difficult for GUIs.  Does 
that make it necessary to "hunt for exceptions" like that instead of testing 
for results correctness?  It may also be just my short experience with 
Python and especially my total lack of experience with complex systems in 
Python (e.g, Zope), so I'm ready to listen to an argument on that point.

Dan

> -- David