[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