[Dev] Re: raise problem
Phillip J. Eby
pje at telecommunity.com
Fri Feb 18 07:06:28 PST 2005
At 10:20 PM 2/17/05 -0800, Andi Vajda wrote:
>>At 07:37 PM 2/17/05 -0800, Morgen Sagen wrote:
>>>raise takes 3 arguments:
>
>>>http://www.python.org/doc/current/ref/raise.html#raise
>Yes, there it says.
>
>But here,
>http://www.python.org/doc/current/lib/module-exceptions.html#l2h-280,
>it doesn't (or I couldn't find it).
>
>The bad part, is that I knew this, and had coded it right the first time.
>Upon reviewing the code, I found this 'bug' and 'fixed' it.
>So, I fixed it again, this time commenting the unobvious, somewhat
>documented, use of the 3rd argument.
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.
>>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]
>>
>>This is basically wrapping the original exception instance
>>(exc_info()[1]) in an ImportError, and reusing the traceback. I'm using
>>sys.exc_info() instead of sys.exc_value and exc_traceback because those
>>variables are not threadsafe nor frame-specific, as exc_info() is. (See
>>http://www.python.org/doc/current/lib/module-sys.html for details.)
More information about the Dev
mailing list