超简单的Python教程系列——第6篇：错误异常

Posted 2022-09-07 飞天程序猿

Exceptions

许多程序员的宿敌之一。在许多语言中，我们习惯将异常与某种程度的失败联系起来。某事，某处，被不当使用。

如果我告诉你，你不必害怕异常呢？他们想成为你的朋友并帮助你编写更好的代码？

Python 提供了许多友好的错误异常处理工具，但我们使用它们的方式可能看起来与你习惯的完全不同，它可以帮助你做的不仅仅是清理混乱。甚至可以说，Python 中的错误处理强大在内部。

开始捕捉

以防万一你不熟悉异常，让我们从一般定义开始......

exception：（计算）正常处理时发生的中断，通常由错误条件引起，可由另一部分程序处理。

让我们看一个简单的例子：

def initiate_security_protocol(code):
    if code == 1:
        print("Returning onboard companion to home location...")
    if code == 712:
        print("Dematerializing to preset location...")

code = int(input("Enter security protocol code: "))
initiate_security_protocol(code)

>>> Enter security protocol code: 712
Dematerializing to preset location...
>>> Enter security protocol code: seven one two
Traceback (most recent call last):
  File "/home/jason/Code/FiringRanges/PyFiringRange/Sandbox/security_protocols.py", line 7, in <module>
    code = int(input("Enter security protocol code: "))
ValueError: invalid literal for int() with base 10: seven one two

显然，这是一个错误。我们不希望我们的程序因为用户输入了一些奇怪的东西而突然崩溃。正如下面这个笑话所说...

一名 QA 工程师走进一家酒吧。他点了一杯啤酒。他点了五瓶啤酒。他点了 -1 杯啤酒。他点了一只蜥蜴。

我们想防止奇怪的输入。在这种情况下，只有一个重要的故障点：就是​​int()​​函数。它期望接收可以转换为整数的参数，如果它没有得到它，则会抛出​​ValueError​​异常。为了正确处理这个问题，我们将可能失败的代码包装在一个​​try...except​​块中。

try:
    code = int(input("Enter security protocol code: "))
except ValueError:
    code = 0
initiate_security_protocol(code)

当我们再次测试我们的代码时，我们不会遇到这种失败错误。如果我们无法从用户那里获得我们需要的信息，我们将只需要设置​​code=0​​​​。当然，我们可以重写我们的​​initiate_security_protocol()​​​函数来处理​​0​​不同的代码，但是我不会在这里展示，只是为了节省时间。

注意：无论出于何种原因，作为一名多语言程序员，我经常忘记​在 Python 中使用​​except​​​，而用大多数其他语言所使用的​​catch​​语句。我已经在这篇文章中打错了三遍（然后立即修复它）。这只是一个记忆点。值得庆幸的是，Python没有​​catch​​的关键字，因此​语法错误会很突出。如果你会多种语言，当你感到困惑时，请不要惊慌。python里是​​except​​​，不是​​catch​​。

阅读Traceback

在我们深入探讨该​​try...except​​语句的一些更深层次的细节之前，让我们再次回顾一下该错误语句。毕竟，如果我们不讨论错误消息，那么一篇关于错误处理的文章有什么用呢？在 Python 中，我们称之为Traceback，因为它从涉及的第一行代码到最后一行跟踪错误的起源。在许多其他语言中，这将被称为堆栈跟踪( stack trace)。

Traceback (most recent call last):
  File "/home/jason/Code/FiringRanges/PyFiringRange/Sandbox/security_protocols.py", line 7, in <module>
    code = int(input("Enter security protocol code: "))
ValueError: invalid literal for int() with base 10: seven one two

我有从下到上阅读这些信息的习惯，因为它可以帮助我首先获得最重要的信息。如果你查看最后一行，你会看到​​ValueError​​​，这是已引发的特定异常。确切的细节如下；在这种情况下，无法使用 . 将字符串​​seven one two​​用​​int()​​转换为整数。我们还了解到它正在尝试转换为以10 为底的整数，这在其他场景中可能是有用的信息。想象一下，例如，如果那行改成...

ValueError: invalid literal for int() with base 10: 5bff

如果我们忘记指定以 16 为基数进行​​int(5bff, 16)​​转化，而不是默认值（以 10 为基数），这是完全可能的。简而言之，你应该始终彻底阅读并理解错误消息的最后一行！有太多次我看了一半的帖子，花了半个小时追错了bug，才发现我忘记了一个参数或使用了错误的函数。

错误消息上方是错误来自 ( ​​code = int(input("Enter security protocol code: "))​​) 的代码行。上面是文件的绝对路径 ( ​​security_protocols.py​​) 和行号​​7​​。该语句​​in <module>​​意味着代码在任何函数之外。在这个例子中，回调只有一步，所以让我们看一些稍微复杂一点的东西。我已经更改并扩展了之前的代码。

Traceback (most recent call last):
  File "/home/jason/Code/FiringRanges/PyFiringRange/Sandbox/databank.py", line 6, in <module>
    decode_message("Bad Wolf")
  File "/home/jason/Code/FiringRanges/PyFiringRange/Sandbox/databank.py", line 4, in decode_message
    initiate_security_protocol(message)
  File "/home/jason/Code/FiringRanges/PyFiringRange/Sandbox/security_protocols.py", line 2, in initiate_security_protocol
    code = int(code)
ValueError: invalid literal for int() with base 10: Bad Wolf

我们遇到了与以前类似的错误 - 我们正在尝试将字符串转换为整数，但它不起作用。倒数第二行向我们展示了失败的代码；果然，这儿提到了​​int()​​这一点。根据上面的行，这个有问题的代码位于​​security_protocols.py​​文件的第2 行​​initiate_security_protocol()​​函数内部！我们就可以马上找到那儿，并将其包装在一个​​try...except​​. 了解了为什么从下到上阅读可以节省时间了吧？

然而，让我们想象它并不那么简单。也许我们没有修改​​security_protocols.py​​的选项​，所以我们需要在执行该模块之前防止出现问题。如果我们查看下一行，我们会看到在​​databank.py​​​第 4 行，在​​decode_message()​​​函数内部，我们调用的​​initiate_security_protocol()​​​函数有问题。是由于在​​databank.py​​​第6行被调用，这就是我们将参数传递​​"Bad Wolf"​​给它的地方。

数据输入不是问题，因为我们要解码消息“Bad Wolf”。但是，为什么我们要将我们试图解码的消息传递给安全协议呢？也许我们需要改写那个函数（或者除了其他更改之外？）。如你所见，Traceback对于了解错误的来源非常重要。养成仔细阅读的习惯；许多有用的信息可能隐藏在意想不到的地方。

顺便说一句，第一行每次都是一样的，但是如果你忘记如何阅读这些消息，它会非常有用。最近执行的代码列在最后。因此，正如我之前所说，你应该从下往上阅读它们。

Exception

“请求宽恕比获得许可更容易。” -海军少将格蕾丝·霍珀

这句话最初是关于主动的；如果你相信一个想法，请尽力去尝试它，而不是等待其他人的许可来追求它。然而，在这种情况下，它很好地描述了 Python 的错误处理哲学：如果某些事情经常以一种或多种特定方式失败，通常最好使用​​​try...except​​语句来处理这些情况。

这种哲学被正式命名为“请求宽恕比许可更容易”，或​EAFP​。

这有点抽象，所以让我们考虑另一个例子。假设我们希望能够在字典中查找信息。

datafile_index = 
    # Omitted for brevity.
    # Just assume theres a lot of data in here.


def get_datafile_id(subject):
    id = datafile_index[subject]
    print(f"See datafile id.")

get_datafile_id("Clara Oswald")
get_datafile_id("Ashildir")

See datafile 6035215751266852927.

Traceback (most recent call last):
  File "/home/jason/Code/FiringRanges/PyFiringRange/Sandbox/databank.py", line 30, in <module>
    get_datafile_id("Ashildir")
  File "/home/jason/Code/FiringRanges/PyFiringRange/Sandbox/databank.py", line 26, in get_datafile_id
    id = datafile_index[subject]
KeyError: Ashildir

第一个函数调用是对的。我们在字典​​database_index​​​中搜索存在的键​​"Clara Oswald"​​​，因此我们返回与其关联的值 (​​6035215751266852927​​ )，并在我们格式化语句​​print()​​​中打印出该数据。但是，第二个函数调用失败。引发异常​​KeyError​​​，因为​​"Ashildir"​​它不是字典中的键。

技术说明： Python 为​​collections.defaultdict​​这个确切问题提供了另一种解决方案；尝试访问不存在的键将使用一些默认值在字典中创建键/值对。但是，由于这是演示错误处理的示例，因此我没有使用它。

由于不能合理地期望我们知道或记住字典中的所有键，尤其是在现实世界的场景中，我们需要一些方法来处理尝试访问不存在的键的常见情况。你的第一直觉可能是在尝试访问字典键之前检查它......

def get_datafile_id(subject):
    if subject in datafile_index:
        id = datafile_index[subject]
        print(f"See datafile id.")
    else:
        print(f"Datafile not found on subject)

在 Python 文化中，这种方法被称为“跳前看”[LBYL]。

但这不是最有效的方法！“宽恕，而不是许可”在这里发挥作用：我们不是先测试，而是使用​​​try...except​​.

def get_datafile_id(subject):
    try:
        id = datafile_index[subject]
        print(f"See datafile id.")
    except KeyError:
        print(f"Datafile not found on subject")

这背后的逻辑很简单：我们不是通过两次获取键，而是只访问一次，并使用实际exception作为逻辑分支的手段。

在 Python 中，我们不认为异常是可以避免的。事实上，​​try...except​​它是许多 Python 设计模式和算法的常规部分。不要害怕引发和捕获异常！事实上，即使是键盘中断也是通过​​KeyboardInterrupt​​异常处理的。

注意： ​​try...except​​​是一个强大的工具，但它并不适用于一切。例如，​​None​​从函数返回通常被认为比引发异常更好。仅在发生最好由调用者处理的实际错误时抛出异常。

​

反面模式

迟早，每个 Python 开发人员都会发现这是可行的：

try:
    someScaryFunction()
except:
    print("An error occured. Moving on!")

一个单​​except​​语句允许你在一个中捕获所有异常。这个被称为反面模式，这是一个非常非常糟糕的想法。总结一下……

...实际错误的所有上下文放在了一起抛出，永远看不到问题跟踪器的内部。当发生“大量”异常时，堆栈跟踪指向发生次要错误的位置，而不是 try 块内的实际失败位置。

长话短说，你应该始终明确地捕获特定的异常类型。任何你无法预见的失败都可能与一些需要解决的错误有关；例如，当你的超级复杂搜索功能突然开始提出 an​​OSError​​而不是预期的​​KeyError​​或者​​TypeError​​时。

像往常一样，The Zen Python 对此有话要说……

错误永远不应该悄无声息地过去。
除非明确沉默。

换句话说，这不是口袋妖怪 - 你不应该抓住他们！

​

Except, Else, Finally

我不会一下子就捕捉到所有异常。那么，如何处理多个可能的故障呢？

你要知道 Python 的​​try...except​​工具比它最初展示的要多得多。

class SonicScrewdriver:

    def __init__(self):
        self.memory = 0

    def perform_division(self, lhs, rhs):
        try:
            result = float(lhs)/float(rhs)
        except ZeroDivisionError:
            print("Wibbly wobbly, timey wimey.")
            result = "Infinity"
        except (ValueError, UnicodeError):
            print("Oy! Dont diss the sonic!")
            result = "Cannot Calculate"
        else:
            self.memory = result
        finally:
            print(f"Calculation Result: result\\n")


sonic = SonicScrewdriver()

sonic.perform_division(8, 4)
sonic.perform_division(4, 0)
sonic.perform_division(4, "zero")

print(f"Memory Is: sonic.memory")

在我向你展示输出之前，请仔细查看代码。你认为这三个​​sonic.perform_division()​​​函数调用中的每一个都会打印出什么？最终存储​​sonic.memory​​的是什么？看看你能不能弄明白。

如果你已经有答案？让我们看看你是否正确。

Calculation Result: 2.0

Wibbly wobbly, timey wimey.
Calculation Result: Infinity

Oy! Dont diss the sonic!
Calculation Result: Cannot Calculate

Memory Is: 2.0

你是惊讶，还是你做对了？让我们分析一下。

​​try:​​当然，是我们试图运行的代码，它可能会也可能不会引发异常。

​​except ZeroDivisionError:​​当我们试图除以零时发生。在这种情况下，我们说该值​​"Infinity"​​是计算的结果，并打印出一条关于除以0的提示信息。

​​except (ValueError, UnicodeError):​​只要引发这两个异常之一，就会抛出异常。​​ValueError​​是每当我们传递的任何参数都不能被强制转换​​float()​​时，就会发生这种错误，而​​UnicodeError​​是如果编码或解码 Unicode 有问题，就会发生这种报错。实际上，第二个只是为了说明一点。对于​​ValueError​​所有无法将参数转换为浮点数的可信场景，这已经足够了。无论哪种情况，我们都将值​​"Cannot Calculate"​​作为我们的结果，并提醒用户不要对硬件提出不合理的要求。

这就是事情变得有趣的地方。仅在未引发异常时​​else:​​运行。在这种情况下，如果我们有一个有效的除法计算结果，我们实际上希望将它存储在内存中；相反，如果我们得到“无穷大”或“无法计算”作为我们的结果，我们不会存储它。

无论如何，该​​finally:​​部分都会运行。在这种情况下，我们打印出我们的计算结果。

顺序确实很重要。我们必须遵循模式​​try...except...else...finally​​，​​else​​如果存在，必须在所有​​except​​语句之后。​​finally​​总是最后的。

最初很容易混淆​​else​​​和​​finally​​​，因此请确保你了解其中的区别。​​​else​​​​​仅在未引发异常时运行；​​​​finally​​​​每次运行。

​

Finally执行顺序

你希望以下代码实现什么？

class SonicScrewdriver:

    def __init__(self):
        self.memory = 0

    def perform_division(self, lhs, rhs):
        try:
            result = float(lhs)/float(rhs)
        except ZeroDivisionError:
            print("Wibbly wobbly, timey wimey.")
            result = "Infinity"
        except (ValueError, UnicodeError):
            print("Oy! Dont diss the sonic!")
            result = "Cannot Calculate"
        else:
            self.memory = result
            return result
        finally:
            print(f"Calculation Result: result\\n")
            result = -1


sonic = SonicScrewdriver()

print(sonic.perform_division(8, 4))

下面的那​​return​​句话​​else​​应该是事情的结束了吧？其实，不！如果我们运行该代码...

Calculation Result: 2.0

2.0

有两个重要的观察结果：

1. ​​finally​​正在运行，即使在我们的return声明之后。该函数不会像通常那样退出。
2. 该​​return​​​语句确实在​​finally​​块执行之前运行。我们知道这一点是因为结果​​result​​​输出是​​2.0​​​，而不是我们在语句​​finally​​中分配的​​-1​​​。​​

​​finally​每次都会运行，即使你​​​return​​​在​​​try...except​​​结构中的其他地方有。

但是，我也用一个​​os.abort()​​​代替测试了上面的​​return result​​​，在这种情况下，​​finally​​​块永远不会运行；该程序彻底中止。你可以在任何地方直接停止程序执行，Python 只会放弃它正在做的事情并退出。该规则是不变的，即使是不寻常的​​finally​​行为。

抛出异常

所以，我们可以用​​try...except​​捕获异常. 但是如果我们只是想主动抛出一个呢？

在 Python 术语中，我们说我们引发了异常，并且与该语言中的大多数事情一样，实现这一点很明显：只需使用​​raise​​关键字：

class Tardis:

    def __init__(self):
        pass

    def camouflage(self):
        raise NotImplementedError(Chameleon circuits are stuck.)

tardis = Tardis()
tardis.camouflage()

当我们执行该代码时，我们会看到我们引发的异常。

Traceback (most recent call last):
  File "/home/jason/Code/FiringRanges/PyFiringRange/Sandbox/tardis.py", line 10, in <module>
    tardis.camoflague()
  File "/home/jason/Code/FiringRanges/PyFiringRange/Sandbox/tardis.py", line 7, in camoflague
    raise NotImplementedError(Chameleon circuits are stuck.)
NotImplementedError: Chameleon circuits are stuck.

这样就能知道我们在哪儿出现了异常错误。

注意：异常NotImplementedError是Python 中的内置异常之一，有时用于指示一个函数不应该使用，因为它还没有完成（但总有一天会完成）。它不能与NotImplementedvalue互换。请参阅文档以了解何时使用它们。

显然，关键代码是​​raise NotImplementedError(Chameleon circuits are stuck.)​​​. 在​​raise​​关键字之后，我们给出要引发的异常对象的名称。在大多数情况下，我们从 Exception 类创建一个新对象，从括号的使用可以看出。所有异常都接受字符串作为消息的第一个参数。一些例外接受或需要更多参数，因此请参阅官方文档。

使用异常

有时我们需要在捕捉到异常后对其进行处理。我们有一些非常简单的方法来做到这一点。

最明显的是从异常中打印消息。为此，我们需要能够处理我们捕获的异常对象。让我们将​​except​​语句更改为​​except NotImplementedError as e:​​，其中​​e​​是我们“绑定”到异常对象的名称。然后，我们可以​​e​​直接作为对象使用。

tardis = Tardis()

try:
    tardis.camouflage()
except NotImplementedError as e:
    print(e)

异常类已经定义了它的​​__str__()​​函数来返回异常消息，所以如果我们将它转​​换成一个字符串（​​str()​​），这就是我们将得到的。你可能还记得上一篇文章​​print()​​自动将其参数转换为字符串。当我们运行这段代码时，我们得到...

Chameleon circuits are stuck.

是不是很容易！

冒泡

现在，如果我们想再次引发异常怎么办？

等等，什么？我们刚刚捕获了那个东西。为什么还要再次引发异常？

一个示例是，如果你需要在幕后进行一些清理工作，但最终仍希望调用者必须处理异常。这是一个例子......

class Byzantium:

    def __init__(self):
        self.power = 0

    def gravity_field(self):
        if self.power <= 0:
        raise SystemError("Gravity Failing")


def grab_handle():
    pass


byzantium = Byzantium()

try:
    byzantium.gravity_field()
except SystemError:
    grab_handle()
    print("Night night")
    raise

在上面的示例中，我们只是想捕获一些实体 ( ​​grab_handle()​​) 并打印一条附加消息，然后让异常继续​​raise​​抛出. 当我们重新引发异常时，我们说它冒泡了。

Night night
Traceback (most recent call last):
  File "/home/jason/Code/FiringRanges/PyFiringRange/Sandbox/byzantium.py", line 18, in <module>
    byzantium.gravity_field()
  File "/home/jason/Code/FiringRanges/PyFiringRange/Sandbox/byzantium.py", line 8, in gravity_field
    raise SystemError("Gravity Failing")
SystemError: Gravity Failing

注意：你可能认为我们需要说​​except SystemError as e:​​或者说​​raise e​​什么，但那是矫枉过正。对于冒泡的异常，我们只需要自己调用​​​raise​。

现在，如果我们想在冒泡异常的同时添加一些额外的信息怎么办？你的第一个猜测可能只是完全引发一个新异常，但这会带来一些问题。为了演示，我将在执行顺序中添加另一层。请注意，当我处理这个问题时​​SystemError​​，我会提出一个新的​​RuntimeError​​。我在第二个​​try...except​​区块中发现了这个新异常。

byzantium = Byzantium()

def test():
    try:
        byzantium.gravity_field()
    except SystemError:
        grab_handle()
        raise RuntimeError("Night night")

try:
    test()
except RuntimeError as e:
    print(e)
    print(e.__cause__)

当我们运行它时，我们得到以下输出。

Night night
None

当我们捕获到这个新异常时，我们完全没有关于它是什么原因的上下文。为了解决这个问题，Python 3在PEP 3134中引入了显式异常链接。实现它很容易。看看我们的新函数​​test()​​，这是我与上一个示例相比唯一更改的部分。

byzantium = Byzantium()

def test():
    try:
        byzantium.gravity_field()
    except SystemError as e:
        grab_handle()
        raise RuntimeError("Night night") from e

try:
    test()
except RuntimeError as e:
    print(e)
    print(e.__cause__)

你有没有发现我在那儿做什么？在​​except​​声明中，我将名称绑定​​e​​到我们捕获的原始异常。然后，在引发新​​RuntimeError​​异常时，我将其链接到上一个异常，并使用​​from e​​. 我们现在的输出...

Night night
Gravity Failing

当我们运行它时，我们的新异常会记住它是从哪里来的——前一个异常存储在它的​​__cause__​​属性中（打印在输出的第二行）。这对于日志记录特别有用。

你可以使用异常类执行许多其他技巧，尤其是在引入 PEP 3134 时。像往常一样，我建议你阅读文档，我在文章末尾链接到该文档。

自定义异常

Python 有一大堆异常，它们的使用有据可查。当我为工作选择合适的异常时，我经常参考这个异常列表。然而，有时，我们只需要更多……定制的东西。

超简单的Python教程系列——第18篇：调试

超简单的Python教程系列——第12篇：文件处理

超简单的Python教程系列——第8篇：迭代工具

超简单的Python教程系列——第15篇：多线程

超简单的Python教程系列——第4篇：数据类型和不变性

超简单的Python教程系列——第13篇：上下文管理器