[Dev] Re: raise problem

Andi Vajda vajda at osafoundation.org
Fri Feb 18 10:19:57 PST 2005


> Just FYI, your fix is not thread-safe; if an error (even as simple as a 
> transient KeyError or AttributeError) occurs in another thread between the 
> __import__ and the raise statements, you will re-raise that thread's value 
> and traceback, not the one you want.  sys.exc_value and sys.exc_traceback 
> have been deprecated for years because of this issue; see the sys module page 
> referenced below.  Naturally, for this particular use case it may not matter 
> much, but it seems worth pointing out.

Ouch, you're right. I fixed it again to use the non-deprecated, thread-safe 
exc_info() values instead.

>>> Anyway, the specific code in question should just use zero-argument raise, 
>>> unless there's some reason that clients of ClassLoader want all exceptions 
>>> to be transformed into ImportError, in which case the correct form would 
>>> be this rather ugly three-argument form:
>>> 
>>>    raise ImportError, ImportError(sys.exc_info()[1]), sys.exc_info()[2]

The new code says:
        x, value, traceback = sys.exc_info()
        raise ImportError, value, traceback
which is less ugly and does what I intended all along.
Why do/did I want to raise ImportError to being with ?

Well, when I originally wrote this code I knew very little python and I 
thought that when importing a class, failures should be reported as import 
errors as a matter of protocol. This is a hangover from my Java days.

Andi..



More information about the Dev mailing list