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

[Dan Perl]

"David Bolen" <db3l at fitlinxx.com> wrote in message 
news:u655yi527.fsf at fitlinxx.com...
> ...................
> Even if you do have a console showing exceptions, not all exceptions
> are cleanly reproduceable or predictable.  I may have code that
> typically runs just great, but that occasionally generates an
> exception.  Breakpoints may not work if the code runs many times
> successfully before failing (due to varieties in calling parameters at
> runtime).  Perhaps a watchpoint might work but you'd have to know
> enough about the failure to establish the watchpoint parameters.
>
> Instead, with Wing, just start it up, let it run (or if you need to,
> run it independently of Wing but with the stub loaded) until the
> exception occurs.  No hassles or up front work.

Okay, I can see this point.  The idea of the loaded stub sounds especially 
interesting because you can just run the application normally, independent 
of an IDE.  In my experience with sporadic problems like the ones you are 
describing, debuggers are usually not much help, except after the fact, for 
instance debugging a core of a C/C++ program.  If the problem is caused by a 
race condition, a debugger can be useless because it affects the scheduling 
of threads.  How does the loaded stub work in cases like that?  Does it 
affect threads in any way?

>> 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.
>
> Did you get any others?  I was talking "minimal" in terms of volume,
> not necessarily significance (which may be more subjective).  I didn't
> have much of an issue choosing to ignore the sre case (after which it
> never showed up again for my project).

It was the only one.  My point was that even just this particular exception 
should happen very often.  So even volume, not only significance, is 
relative.  I, for one, was not comfortable ignoring an exception, especially 
without a very clear and detailed explanation on why the false positive 
happened in the first place and what happens with the exception if I ignore 
it.

> (...)
>> 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'd split that into two parts - (a) generating the exception without
> knowing it, and (b) it being relevant even if handled.
>
> For (a), I can't seem to come up with a good concise example, so maybe
> I'll just agree that you may know about, but not be able to act on it
> in a useful fashion.  (The cases I was thinking of were GUI apps
> without a console, or apps generating output where a traceback might
> be missed, but I can come up with reasonable solutions in those cases
> if you knew you were looking for an exception, so I'm willing to bet
> you can too.  The other case was with a locally developed extension, but
> that's susceptible to the argument of just fixing the local extension :-))
>
> Note however, that knowing about it in many cases may only be through
> a stderr traceback, so to know it other than manually inspecting it at
> runtime would require trapping stderr in general and logging that
> somewhere, and then having something to recognize tracebacks in that
> log.
>
> (b) is certainly possible though, although at the risk of overuse I'll
> fall back to wxPython again.  In wxPython any exception that occurs in
> an event handler will be handled by the wxPython extension, and is
> thus invisible to top level code.  So if you have an exception in an
> event handler, it interrupts the exception handler, which presumably
> no longer does what it is supposed to, so that's relevant.  The
> exception will not, however, stop the application, nor bubble up to
> any top level application exception handler.  The only place you'd see
> an indication of it would be in the traceback to stderr - your
> application has no opportunity to handle it otherwise (unless you have
> exception handlers in each individual event handler).
>
> Now in normal operation that's actually a very attractive part of
> wxPython.  By and large you can create problems, and the application
> keeps running.  Perhaps one element of the GUI might not react
> properly or some button won't work, but the application survives.  But
> when trying to troubleshoot that problem, it's often most convenient
> to interact with the application as a user until the problem occurs,
> letting the debugger simply catch things at the point when it happens.

You're making a very good case, assuming that the exception is at the root 
of the problem.  However, it's hard to say how many such problems are caused 
by an exception.  Even if there is an exception, the root problem may be way 
before that and you still have to go and do some normal debugging.  So many 
times I've had memory corruption crashing an application in C++ and I had to 
look back at a method that was called WAY BEFORE the crash because that was 
usually corrupting memory at exit.

So, in your example of a button, my general debugging approach would still 
be to put a breakpoint in the event handler of the button, because the root 
of the problem can be so many different things.

In your experience with Python, what percentage of problems manifested 
themselves with exceptions (especially right at the root of the problem) as 
opposed to simply flawed logic that gets through without any exceptions?

I think we are actually very much agreeing.  The main difference between us 
is how much weight we put in debugging exceptions versus debugging all kinds 
of problems and how much we are willing to put up with in exchange for that 
precious advantage in a few cases.

You are saying a solid debugger "can be worth its weight in gold".  How much 
does Wing IDE weigh?   ;-)

Dan

> -- David