[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