Any way to turn off exception handling? (debugging)

[Peter Otten]

mk wrote:

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

You could try to shadow the exception class with None:

>>> ZeroDivisionError = None
>>> try:
...     1/0
... except ZeroDivisionError:
...     print "caught"
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
ZeroDivisionError: integer division or modulo by zero

Applying that technique on a module containing

try: 
   ...
except socket.error: 
   ...

#untested
import socket

class SocketWrapper:
    def __getattr__(self, name):
        return getattr(socket, name)
    error = None

import module_using_socket
module_using_socket.socket = SocketWrapper()

Peter