关于python：条件检查与异常处理

Condition checking vs. Exception handling

本问题已经有最佳答案，请猛点这里访问。

什么时候处理异常比检查条件更可取？在很多情况下，我可以选择使用其中一个。

例如，这是一个使用自定义异常的求和函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# module mylibrary
class WrongSummand(Exception):
pass

def sum_(a, b):
""" returns the sum of two summands of the same type"""
if type(a) != type(b):
raise WrongSummand("given arguments are not of the same type")
return a + b

# module application using mylibrary
from mylibrary import sum_, WrongSummand

try:
print sum_("A", 5)
except WrongSummand:
print"wrong arguments"

这是相同的函数，避免使用异常

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# module mylibrary
def sum_(a, b):
""" returns the sum of two summands if they are both of the same type"""
if type(a) == type(b):
return a + b

# module application using mylibrary
from mylibrary import sum_

c = sum_("A", 5)
if c is not None:
print c
else:
print"wrong arguments"

我认为使用条件总是更易于阅读和管理。还是我错了？定义引发异常的API的适当情况是什么？为什么？

相关讨论

实际上，使用异常的问题在于业务逻辑。如果情况是例外(即根本不应该发生)，则可以使用例外。但是，如果从业务逻辑的角度来看情况是可能的，那么在应该通过条件检查进行处理时，即使这种情况看起来更复杂。

例如，这里是我在准备语句中遇到的代码，开发人员在设置参数值(Java，而不是Python)：

1
2
3
4
5
6

// Variant A
try {
ps.setInt(1, enterprise.getSubRegion().getRegion().getCountry().getId());
} catch (Exception e) {
ps.setNull(1, Types.INTEGER);
}

通过条件检查，可以这样写：

1
2
3
4
5
6
7
8

// Variant B
if (enterprise != null && enterprise.getSubRegion() != null
&& enterprise.getSubRegion().getRegion() != null
&& enterprise.getSubRegion().getRegion().getCountry() != null) {
ps.setInt(1, enterprise.getSubRegion().getRegion().getCountry().getId());
} else {
ps.setNull(1, Types.INTEGER);
}

从第一眼看，变体B似乎要复杂得多，但是，它是正确的，因为从商业的角度来看，这种情况是可能的(可能没有指定国家)。使用异常会导致性能问题，并且会导致对代码的误解，因为不清楚，国家是否可以接受为空。

在企业中使用辅助功能可以改进变量B，企业将立即返回地区和国家：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public RegionBean getRegion() {
if (getSubRegion() != null) {
return getSubRegion().getRegion();
} else {
return null;
}
}

public CountryBean getCountry() {
if (getRegion() != null) {
return getRegion().getCountry();
} else {
return null;
}
}

这段代码使用了类似于链接的方法，并且每个get方法看起来足够简单，并且只使用了一个前置任务。因此，变量B可以改写如下：

1
2
3
4
5
6

// Variant C
if (enterprise != null && enterprise.getCountry() != null) {
ps.setInt(1, enterprise.getCountry().getId());
} else {
ps.setNull(1, Types.INTEGER);
}

另外，请阅读这篇Joel文章，了解为什么不应过度使用异常。还有陈瑞蒙的一篇文章。

我选择异常状态返回的主要原因是考虑如果程序员忘记做他的工作会发生什么。除了例外，您可能会忽略捕获异常。在这种情况下，您的系统将明显失败，您将有机会考虑在哪里添加捕获。对于状态返回，如果您忘记检查返回，它将被静默忽略，并且您的代码将继续运行，稍后可能会以一种神秘的方式失败。比起看不见的失败，我更喜欢看不见的失败。

还有其他原因，我在这里解释过：异常与状态返回。

如果你在问，你可能应该使用例外。例外是用来表示特殊情况的，这是一种特殊情况，在这种情况下，事情的工作方式与其他情况不同。这是一个很好的例子，几乎所有的错误，以及许多其他的事情。

在您的第二个sum_实现中，用户必须每次检查值是什么。这让人想起C/Fortran/其他语言样板文件(以及常见的错误源)，其中错误代码未经检查是我们所避免的。您必须在所有级别编写这样的代码才能传播错误。它会变得混乱，尤其是在Python中避免。

其他几个注意事项：

你通常不需要自己做例外。在许多情况下，像ValueError和TypeError这样的内置异常是适当的。
当我确实创建了一个新的异常，这非常有用，我经常尝试将比Exception更具体的子类化。这里是内置的异常层次结构。

我绝不会实现像sum_这样的函数，因为类型检查会降低代码的灵活性、可维护性和惯用性。

我只写函数

1 2	def sum_(a, b): return a + b

如果对象是兼容的，如果不是兼容的话，它就会抛出一个例外，每个人都习惯看到的TypeError。考虑我的实现是如何工作的

1
2
3
4
5
6
7
8
9
10
11
12
13

>>> sum_(1, 4)
5
>>> sum_(4.5, 5.0)
9.5
>>> sum_([1, 2], [3, 4])
[1, 2, 3, 4]
>>> sum_(3.5, 5) # This operation makes perfect sense, but would fail for you
8.5
>>> sum_("cat", 7) # This makes no sense and already is an error.
Traceback (most recent call last):
File"<stdin>", line 1, in <module>
File"<stdin>", line 1, in sum_
TypeError: cannot concatenate 'str' and 'int' objects

我的代码更短、更简单，但比您的代码更健壮、更灵活。这就是为什么我们避免在python中进行类型检查。