Any way to turn off exception handling? (debugging)

[mk]

> the uncommon, the exceptional, case. If one could somehow turn off 
> exceptions, you can't even do a for loop: every for loop would become 
> infinite-- exceptions are how Python signals the end of an iterator. 
> Think about that, *every* for loop in Python suddenly breaks. 

Ouch.

>     Sure I can, but how do I get out of Python the info *what called
>     particular class/instance*? That is, how do I know who's the caller?
> 
> 
> Um... run your code in a debugger.

..except the code in question is multithreaded and pdb is no good for 
that, and last time I checked, yappi was broken.

> 
> That's what debugger's are -for-.
> 
> "pdb" is a simple one. Various IDE's have more advanced ones.

I tried using pdb on paramiko and my own threaded code, lost some hair 
in the process, and gave up. It's good for tracing the main thread, 
basically, not for threading.Threads.

> I think you're better served showing us what, "I'm getting an exception 
> (on socket) handled..." actually means, what is actually happening with 
> real code and output, and getting pointers on where to look, then trying 
> to gather material to support an honestly impossible change :)

I'm using a threaded library paramiko (probably by now half of this 
group is sick of hearing me saying this again). 2 of (rather broken) 
hosts (Solaris, Linux) are really, really slow when responding over SSH, 
like a minute for a key exchange. In paramiko, timeout doesn't work bc 
the timeout specified there is timeout for a socket and not for SSH.

When calling transport.socket.close() via threading.Timer like this:

def printandclose(self):
     print "\ntrying to close transport.sock"
     self.trans.sock.close()
     self.flag = True


self.flag = False
timer = threading.Timer(4, self.printandclose)
timer.start()
self.trans.start_client()
timer.cancel()

... I'm getting this on the console:

ERROR (9, 'Bad file descriptor')

According to a guy who is very knowledgable on the library (thanks for 
all the help, James) this is result of catching socket.error somewhere 
in paramiko code, like "except socket.error".

I need to find that place. On top of lack of proper handling of 
timeouts, this is important bc when calling paramiko SSHClient.connect() 
(which in turn uses the same machinery as transport.start_client IIRC) 
paramiko uses close to 100% of CPU when negotiating with such broken or 
unresponsive hosts.

For my reasons, I need to get this fixed.

Regards,
mk