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

[David Bolen]

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

> Interesting.  So it's actively attached to the process, not just listening 
> to it.  I would like to find out more about how this debug stub works.  The 
> Wing IDE reference manual doesn't get into details like that, but I can see 
> that one can also set breakpoints remotely.  That should mean that the stub 
> does quite a bit of work.

It's been a while, but if I recall the stub operates like a network
client, just connecting back to the IDE.  It tries to connect when
imported.  If it can't connect it sits around (in a background thread
I think) periodically trying - that shouldn't be much overhead.  But
when connected, it invokes the normal wing debugging code (e.g., the
same stuff used when debugging an app locally) which I'm assuming ties
into sys.settrace or equivalent and uses the network link to exchange
the information with the IDE.  I'm assuming sys.settrace or equivalent
since once connected you can explicitly interrupt the debuggee from
the IDE at any time.

> Since my previous posting on this thread I have discovered an interesting 
> utility for remote reporting of exceptions, although I couldn't try it: 
> http://egofile.com/cgi-bin/blosxom.cgi.  My understanding is that it sends 
> an HTTP POST message.  That should mean that it's much less powerful than 
> the Wing IDE stub but it should be also less intrusive.

Depends on how it traps the exceptions.  If it's using something like
sys.excepthook, then yes, it should definitely be less intrusive (but
also unable to catch anything but unhandled exceptions).  But I would
expect any tool that is actively watching code at a finer granularity
is going to carry similar overhead to a debugger since they probably
all use the existing trace hooks in Python.

> And I also found win32traceutil 
> (http://www.python.org/windows/win32/#win32trace), which has quite a similar 
> use.  Of course, it's only for Windows, and I'm not sure whether it works 
> with the listener and the debugged process on different nodes.  But this is 
> something I may personally use.

I'm pretty sure this is local only.  You can get the source from the
PyWin32 package.  Last time I looked it used a memory mapped file (in
swap space) to hold data pending someone reading from it.  So it's
basically a simple inter-process pipe.  Importing it routes all
stdout/stderr to the trace file so yes it would be a way to catch
unhandled exceptions at least for logging purposes.

It's useful (particularly for when you want to get output from
background stuff like COM servers or GUI applications that for one
reason or another can't have a console during debugging), but strictly
for providing an alternate stdout/stderr stream.

-- David