Detecting an active exception

Steve Holden steve at holdenweb.com
Sat Jun 2 16:21:39 EDT 2007


Duncan Booth wrote:
> "NeBlackCat (lists)" <lists at asd-group.com> wrote:
> 
>> Depending on what you read, sys.exc_info() is supposed to return 
>> (None,None,None) when there is no active exception, but it seems that
>> it returns info about the last exception when there isn't one
>> currently active.
>>
>> For example:
>>
>> try:
>>     a = a + 1
>> except:
>>     pass
>>
>> print sys.exc_info()
>>
>> produces:
>> <class exceptions.NameError at 0x009648D0>, <exceptions.NameError 
>> instance at 0x00B5E508>, <traceback object at 0x00B5E4E0>
>>
>> Where the traceback object identifies the offending a=a+1 line (of
>> course). 
>>
>> Is there another way of doing this? Note that I can't rely on using 
>> sys.exc_clear() in any solution, unfortunately.
> 
> I think you have misunderstood the definition of when an exception is 
> 'currently active'. When an exception is caught, it remains currently 
> active so long as you are in the same function, or in a function which it 
> calls (i.e. so long as the current scope is still active). When you return 
> from that function the exception is no longer active and the previous 
> exception becomes active (or None if there has not been one or you have 
> used sys.exc_clear()).
> 
> Try this:
> --------- t.py -------------
> import sys
> 
> def f():
>     try:
>         a = a + 1
>     except:
>         pass
> 
>     g()
>     print "f", sys.exc_info()
> 
> def g():
>     print "g", sys.exc_info()
> 
> def h():
>     f()
>     print "h", sys.exc_info()
> 
> h()
> ----------------------------
> The output is:
> 
> g (<type 'exceptions.UnboundLocalError'>, UnboundLocalError("local variable 
> 'a' referenced before assignment",), <traceback object at 0x00A8B300>)
> f (<type 'exceptions.UnboundLocalError'>, UnboundLocalError("local variable 
> 'a' referenced before assignment",), <traceback object at 0x00A8B300>)
> h (None, None, None)
> 
> As you can see the exception remains 'currently active' only until the 
> function in which it was caught returns.

Duncan, that's a great description that should go in the docs (I suspect 
you aren't just quoting from them here). Kristján V. Jónsson has also 
raised some great points about this issue in a multi-threaded 
multi-processing application architecture both simplified and 
complicated by the presence of Stackless, though I can't lay my hands on 
any summary of his findings right now.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd           http://www.holdenweb.com
Skype: holdenweb      http://del.icio.us/steve.holden
------------------ Asciimercial ---------------------
Get on the web: Blog, lens and tag your way to fame!!
holdenweb.blogspot.com        squidoo.com/pythonology
tagged items:         del.icio.us/steve.holden/python
All these services currently offer free registration!
-------------- Thank You for Reading ----------------




More information about the Python-list mailing list