2010-04-30 48 views
4

我有一个基本的“最佳实践”Python问题。我发现已经有StackOverflow回答与这个问题切线相关,但他们陷入了复杂的例子或涉及多种因素。基本Python:异常提升和本地变量作用域/绑定

鉴于此代码:

#!/usr/bin/python 

def test_function(): 
    try: 
     a = str(5) 
     raise 
     b = str(6) 
    except: 
     print b 

test_function() 

什么是避免不可避免的最好办法:那我会在异常处理程序来获取“UnboundLocalError赋值之前引用局部变量‘B’”?

python是否有一个优雅的方式来处理这个问题?如果不是,那么一种不雅的方式呢?在一个复杂的函数中,我宁愿避免在我之前测试每个局部变量的存在性,例如,打印关于它们的调试信息。

+2

办理什么定义?假设在“except”条款中打印什么? – SilentGhost 2010-04-30 13:52:12

回答

1
def test_function(): 
    try: 
     a = str(5) 
     raise 
     b = str(6) 
    except: 
     print b 

b = str(6)从不运行;程序在raise之后退出try。如果要在except块中打印一些变量,请在引发异常之前对其进行评估,并将它们放入您抛出的异常中。

class MyException(Exception): 
    def __init__(self, var): 
     self.var = var 

def test_function(): 
    try: 
     a = str(5) 
     b = str(6) 
     raise MyException(b) 
    except MyException,e: 
     print e.var 
+1

千万不要举'例外'。就像在这种情况下,抓住它永远不会理智。如果你将'str'映射为上面不可调用的内容,并且'MemoryError'如果你用完内存并且无法创建这些对象以及许多你无法解释的其他东西,那么这会捕获'TypeError'。 – 2010-04-30 15:21:00

+0

我同意并编辑了这个例子。 – sastanin 2010-04-30 15:43:28

6

可以初始化try块

a = None 
b = None  
try: 
    a = str(5) 
    raise 
    b = str(6) 
except: 
    print b 
8

Does python have an elegant way to handle this?

为了避免打印绑定名称例外以外的变量,最优雅的方式是不打印;第二个最优雅的是确保名称确实受到约束,例如,通过绑定他们在功能的开始(占位符None是流行为此目的)。

If not, what about an inelegant way?

try: print 'b is', b 
except NameError: print 'b is not bound' 

In a complicated function I'd prefer to avoid testing the existence of every local variable before I, for example, printed debug information about them

保持你的函数的简单(即复杂)强烈推荐的。由于霍尔写道:30年前(在他的图灵验收演讲“皇帝的旧衣服”,转载例如,在this PDF):

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

实现和维护简单确实很难:因为你必须实现一定的总功能X,世界上最诱人的诱惑是通过复杂的增加,进入一些复杂的类和各种各样的功能,“巧妙”的黑客,复制和粘贴和编辑一集“驱动式编码”等等。

然而,努力工作,而不是让功能“如此简单以至于有o显然没有缺陷“。如果一个函数很难完全进行单元测试,那么它太复杂了:将它分解(即重构它)到它的自然组件中,即使它需要发掘它们。 (这实际上是强调单元测试有助于代码质量的方法之一:通过激励你不懈地保持所有代码的完美测试,同时促使你在的结构中简化)。