在测试变量有值时,是否有理由决定使用哪一个try或哪些if结构？
例如,有一个函数返回列表或不返回值.我想在处理之前检查结果.以下哪一项更可取,为什么？
result = function();
if (result):
for r in result:
#process items
要么
result = function();
try:
for r in result:
#process items
except TypeError:
pass;
Tim*_*ker 207
你经常听到Python鼓励EAFP风格("比平等更容易要求宽恕")而不是LBYL风格("先看看你跳跃").对我来说,这是效率和可读性的问题.
在您的示例中(假设不是返回列表或空字符串,函数返回列表或者None),如果您希望99%的时间result实际上包含可迭代的内容,我会使用该try/except方法.如果异常真的很特殊,它会更快.如果result是None的时间超过50%,则使用if的可能会更好.
通过一些测量来支持这一点:
>>> import timeit
>>> timeit.timeit(setup="a=1;b=1", stmt="a/b") # no error checking
0.06379691968322732
>>> timeit.timeit(setup="a=1;b=1", stmt="try:\n a/b\nexcept ZeroDivisionError:\n pass")
0.0829463709378615
>>> timeit.timeit(setup="a=1;b=0", stmt="try:\n a/b\nexcept ZeroDivisionError:\n pass")
0.5070195056614466
>>> timeit.timeit(setup="a=1;b=1", stmt="if b!=0:\n a/b")
0.11940114974277094
>>> timeit.timeit(setup="a=1;b=0", stmt="if b!=0:\n a/b")
0.051202772912802175
因此,虽然if声明总是花费你,但设置try/except块几乎是免费的.但Exception实际发生时,成本要高得多.
道德:
try/except用于流量控制,Exceptions实际上是例外时,它最有意义.从Python文档:
EAFP
比许可更容易请求宽恕.这种常见的Python编码风格假设存在有效的键或属性,并且如果假设被证明是错误则捕获异常.这种干净,快速的风格的特点是存在许多
try和except陈述.该技术与 许多其他语言(如C)共有的LBYL风格形成对比.
Bra*_*don 13
您的函数不应返回混合类型(即列表或空字符串).它应该返回一个值列表或只返回一个空列表.然后你不需要测试任何东西,即你的代码崩溃到:
for r in function():
# process items
tzo*_*zot 11
如果我提供的代码乍一看并不明显,您必须在代码示例后阅读说明,请忽略我的解决方案.
我可以假设"没有返回值"表示返回值是None吗？如果是,或者如果"无值"是布尔方式的假,则可以执行以下操作,因为您的代码基本上将"无值"视为"不迭代":
for r in function() or ():
# process items
如果function()返回的内容不是True,则迭代空元组,即不运行任何迭代.这基本上是LBYL.
一般来说，我得到的印象是例外应该保留在特殊情况下。如果result预期永远不会为空（但可能是，例如，如果磁盘崩溃等），则第二种方法是有意义的。另一方面，如果result在正常条件下空是完全合理的，那么用if语句测试它更有意义。
我想到了（更常见的）场景：
# keep access counts for different files
file_counts={}
...
# got a filename somehow
if filename not in file_counts:
file_counts[filename]=0
file_counts[filename]+=1
而不是等价物：
...
try:
file_counts[filename]+=1
except KeyError:
file_counts[filename]=1
以下哪个更可取，为什么？
在这种情况下，跳前先看是可取的。使用异常方法，TypeError 可能发生在循环体的任何位置，它会被捕获并丢弃，这不是您想要的，并且会使调试变得棘手。
（不过，我同意 Brandon Corfman：为“无项目”而不是空列表返回 None 已被破坏。这是 Java 编码人员的一个令人不快的习惯，不应在 Python 或 Java 中看到。）