一、异常基础概念
1. 什么是异常？
程序执行过程中发生的意外情况导致程序崩溃就是异常。试图除以零、或访问不存在的文件时，就会引发异常。Python内置了一套可以应对大多数场景的异常类型。
异常处理机制主要由以下关键字组成：
- try：包含可能引发异常的代码块
- except：捕获并处理特定类型的异常
- else：如果try块没有抛出异常，则执行这里的代码
- finally：无论是否发生异常，都会执行这里的代码，通常用于清理工作
在try块中，Python会尝试执行所有的代码，但一旦遇到异常：
- 立即停止执行try块中的剩余代码
- 跳转到相应的except块处理异常
- 如果没有找到匹配的except块，异常会向上传播
- finally块（如果有）总是会被执行
单个except块捕获单个异常类型，每个错误都有自己的处理方式
try:
# 可能引发异常的代码
result = 10 / 0
except ZeroDivisionError:
print("不能除以零。")
单个except块捕获多个异常类型 ，这些错误都按照同样的错误来处理
try:
# 可能引发异常的代码
pass
except (ZeroDivisionError, IndexError):
# 同时处理多种异常
print("发生了一个错误。")
2. 常见的内置异常类型
- ZeroDivisionError：除以零
- ImportError：导入模块或包失败
- IndexError：访问列表、元组或其他序列类型的索引超出范围
- NameError：访问一个未定义的变量（参考上一章作用域）
- SyntaxError：语法错误
- TypeError：当传递给函数的参数类型不符合函数预期
- ValueError：当传递给函数的参数值不符合预期，但类型正确时抛出
- KeyError：当尝试从字典中获取一个不存在的键时抛出
- OSError：操作系统相关的错误，如文件操作失败
3. 异常的作用
在下面的例子中，我们尝试执行一个除法操作，其中除数是0。在Python中，除以0会引发一个ZeroDivisionError异常。因为我们使用了try和except结构，当这个异常发生时，控制权会传递到except块。
try:
result = 10 / 0
except ZeroDivisionError:
print("不能除以零。")
- 尝试执行：执行
try块中的代码。 - 异常发生：执行到
10 / 0时，由于除数为0，引发ZeroDivisionError异常。 - 捕获异常：
except块检测到ZeroDivisionError类型的异常后，开始执行其下写好的针对该异常的逻辑。 - 处理异常：这里我没写啥处理，就是打印出消息“不能除以零。
- 程序继续：异常被处理后，程序就不会崩溃，而是继续执行
try和except块之后的代码（如果有的话）。
如果我们移除异常处理机制try和except块，代码如下：
result = 10 / 0
没有异常处理机制。以下是这个代码段执行时的步骤：
- 尝试执行：Python尝试执行除法操作。
- 异常发生：在执行
10 / 0时，由于除数为0，引发了ZeroDivisionError异常。 - 程序崩溃：因为没有
try和except块来捕获和处理异常，Python默认行为是打印出异常的类型和详细信息，然后终止程序的执行。
以下是异常信息的大致输出：
Traceback (most recent call last):
File "example.py", line 2, in <module>
result = 10 / 0
ZeroDivisionError: division by zero
通过这个对比，我们可以看到，异常处理机制（try和except）允许程序在遇到错误时以一种可控的方式做出响应，而不是直接崩溃。
但这并不意味着只有使用了try和except结构，程序才会打印异常错误类型。即使没有这些结构，当异常发生时，Python也会打印出异常的类型和详细信息，并终止程序的执行，就像上述例子。
以"小明在路上开车出了车祸"这个场景，解释Python异常处理机制的每个核心概念：
首先，车祸的发生就像程序中的异常，它是客观存在的。不论小明是否投保或者各种应对措施（是否使用try-except），危险驾驶都会导致车祸（只要代码错误就会引发异常）。 现在看看两种不同的情况：
# 情况1：没有任何保险（没有异常处理）
def drive_dangerously():
car_speed = 120
turn_sharp_corner() # 车祸发生！程序直接崩溃
# 相当于小明超速过弯，发生车祸，没有任何应急预案
# 情况2：有了保险保障（有异常处理机制）
def drive_with_insurance():
try:
car_speed = 120
turn_sharp_corner()
except SpeedTooHighError: # 特定类型的事故，超速
...超速的处理方案
except VehicleDamageError as damage: # 特定类型的事故，损坏
# 可以根据具体损伤情况处理
if damage.is_serious():
call_emergency()
else:
visit_repair_shop()
不同类型的异常就像不同类型的交通事故：超速、追尾、爆胎等， except语句就像不同类型事故的应急预案，as关键字捕获的异常信息就像事故报告，记录了具体的损失情况。如果小明的处理方式仅仅是：
try:
drive_car()
except AccidentError:
print("出车祸了！") # 只是记录，没有实际处理
continue_driving() # 继续上路，带着故障
这就像出了车祸只是在现场竖个"这里出事了"的牌子就继续开车。这样做不但解决不了问题，反而可能因为车辆带伤上路而引发更严重的事故（程序带着bug继续运行可能导致更多错误）。正确的做法应该是：
try:
drive_car()
except AccidentError as accident:
if accident.type == "FLAT_TIRE":
change_to_spare_tire() # 实际的解决方案
elif accident.type == "ENGINE_FAILURE":
tow_to_garage() # 另一种实际的处理方式
else:
raise SeriousAccident # 超出处理能力，向上层抛出异常
这就像小明为不同类型的事故都准备了具体的应对方案：爆胎了就换备胎，发动机故障就叫拖车，遇到无法处理的重大事故就呼叫救援（将异常抛给上层处理）。
总结一下异常处理的核心理念：异常是客观存在的，try-except不是用来发现异常，而是用来处理异常。好的异常处理应该包含实际的解决方案，而不是简单地记录错误然后继续运行。
三、自定义异常
通过继承Python内置的Exception类（或其他已存在的异常类）来创建自定义异常：
class MyCustomError(Exception):
"""这是一个自定义异常的示例"""
def __init__(self, message="这是一个自定义异常"):
self.message = message
super().__init__(self.message)
使用raise关键字可以抛出异常：
def check_value(x):
if x < 0:
raise MyCustomError("不能接受负数")
return x
自定义异常和系统内置异常在本质上有一个根本的区别：
系统内置异常（如ZeroDivisionError）是由Python解释器自动检测和触发的。当Python执行代码时，解释器会自动监控一些基本操作，比如除法运算、列表索引、字典查找等。这些检测机制是用C语言直接写在Python解释器的代码中的。举个例子：
result = 10 / 0 # Python解释器自动检测到除数为0并抛出ZeroDivisionError
numbers = [1, 2, 3]
value = numbers[5] # Python解释器自动检测到索引越界并抛出IndexError
而自定义异常完全不同。它只是一个用来传递错误信息的容器，需要我们在代码中主动检测错误条件并手动抛出。比如：
class InsufficientFundsError(Exception):
pass
class BankAccount:
def withdraw(self, amount):
if amount > self.balance:
# 这里需要我们自己编写检查逻辑并主动抛出异常
raise InsufficientFundsError(f"余额不足: 需要{amount}元，但只有{self.balance}元")
这就像是两种不同的警报系统：
- 系统内置异常就像烟雾报警器，能自动检测到火灾并报警
- 自定义异常则更像是手动报警按钮，需要人为判断情况并按下按钮
自定义异常的主要用途是：
- 给错误条件一个有意义的名字
- 为错误提供更详细的上下文信息
- 允许代码以统一的方式处理业务逻辑错误
理解这个区别很重要，因为它帮助我们更好地理解什么时候应该创建自定义异常，什么时候应该使用系统内置异常。通常，我们创建自定义异常是为了表达业务逻辑层面的错误，而不是取代那些Python已经能自动检测的基本程序错误。
四、异常的抛出与传播机制
1. raise关键字的使用
# 方式1：重新抛出原始异常
try:
x = 1 / 0
except:
print("捕获错误后...")
raise # 重新抛出原始异常
# 方式2：抛出新的异常
try:
x = 1 / 0
except:
print("捕获错误后...")
raise ValueError("抛出新异常")
2. 异常的传播机制
异常会沿着调用栈向外传播，直到被捕获或导致程序终止：
def inner_function():
print("In inner_function.")
raise ValueError("Something went wrong!")
def outer_function():
try:
inner_function()
except ValueError as e:
print(f"Caught an exception: {e}")
# 调用
outer_function()
五、异常处理在框架中的应用
1. Django中的ValidationError
Django框架中的ValidationError是一个典型的自定义异常应用：
from django.core.exceptions import ValidationError
def 坐标格式验证函数(start, end):
try:
start_lat, start_lng = map(float, start.split(','))
end_lat, end_lng = map(float, end.split(','))
if not (-90 <= start_lat <= 90) or not (-90 <= end_lat <= 90):
raise ValidationError("纬度值必须在 -90 到 90 之间")
if not (-180 <= start_lng <= 180) or not (-180 <= end_lng <= 180):
raise ValidationError("经度值必须在 -180 到 180 之间")
except ValueError:
raise ValidationError("坐标格式不正确，应为 'lat,lng'")
2. 在API视图中的应用：
class RouteAPIView(APIView):
def get(self, request, format=None):
start = request.query_params.get('start')
end = request.query_params.get('end')
try:
self.validate_coordinates(start, end)
except ValidationError as ve:
return Response(
{"error": str(ve)},
status=status.HTTP_400_BAD_REQUEST
)
return Response({"message": "路径规划成功"})
六、异常处理与资源管理的关系
- 异常处理：处理程序执行过程中的错误情况
- 资源管理：确保程序资源（如文件、网络连接）被正确使用和释放
两者常通过with语句结合使用
try:
with open("example.txt", "r") as file:
data = file.read()
# 处理数据
except FileNotFoundError:
print("文件未找到。")
except IOError:
print("读取文件时发生错误。")
finally:
print("执行清理工作。")
七、最佳实践建议
- 选择性捕获异常：只捕获你能处理的异常，避免使用空的except语句捕获所有异常
- 合理使用异常处理：对于可预见的错误，使用条件判断，对于不可预见的错误，使用异常处理
- 资源管理：使用with语句管理资源，确保在异常发生时也能正确释放资源
- 避免异常滥用：不要用异常处理来控制正常的程序流程
八、断言(assert)和try-except
就像你写代码时自己加的检查点，确保程序按你的预期在运行，如果assert的条件为False，就说明"程序出bug了"。相当于在马路入口就拦住了酒驾的司机，根本不给他上路的机会，异常处理则是等酒驾司机已经上路，发生事故后再来处理。因此断言是一种"预防胜于治疗"的理念：
- 它帮助我们在问题发生前就发现并阻止不安全的操作
- 它强制程序必须满足某些前提条件才能继续执行
- 它使代码的安全性要求明确且可见
这就是为什么在关键的程序检查点，断言往往比异常处理更加合适。
可以这样理解：断言就像工地的质检员：检查建材是否合格，发现不合格就立即停工，目的是防止质量问题。try-except就像驾驶员：预料到可能会遇到红灯、行人，遇到情况时知道该如何处理，而不是遇见一个障碍，哎，报错了，我也不绕路，我就退出来，我也不走了。 之前看到过一个代码，好像是W3school中的一个例子，其中这个例子很有意思，准确讲这样设计是不对的，虽然可以在try里面写assert，但这违背了两者的设计初衷：assert是用来发现程序bug的，你把它放在try里捕获，就像"明知道房子有问题，还打算住进去"
try:
print(1)
assert 2 + 2 == 5 # 这是一个检查点
except AssertionError:
print(3)
except:
print(4)
记住：断言是帮你找bug的工具，不是用来处理正常运行中的错误的！
通过实际的Web应用开发场景来解释断言和异常处理的根本区别。在开发一个用户注册系统时，我们会遇到两类完全不同的情况：程序内部的逻辑验证和外部资源的交互。对于程序内部的逻辑验证，比如用户输入的基本检查，使用断言是合适的：
def register_user(username, password, age, email):
# 使用断言检查参数的基本有效性
assert isinstance(username, str), "用户名必须是字符串"
assert len(password) >= 8, "密码长度不能小于8位"
assert isinstance(age, int), "年龄必须是整数"
assert '@' in email, "邮箱格式无效"
这些断言检查的都是程序逻辑层面的前提条件，它们是确定的、不变的规则。如果这些条件不满足，说明程序本身存在逻辑错误，应该在开发阶段就被发现和修复。
但是当涉及到外部资源交互时，情况就完全不同了。例如，在注册过程中需要：
def create_user_account(user_data):
try:
# 检查用户名是否已存在
result = database.query("SELECT * FROM users WHERE username = ?", user_data.username)
# 发送验证邮件
email_service.send_verification(user_data.email)
# 创建用户目录
os.makedirs(f"/user_data/{user_data.username}")
except DatabaseConnectionError:
# 数据库可能突然断开连接
log_error("数据库连接失败")
retry_later()
except EmailServerError:
# 邮件服务器可能暂时不可用
log_error("邮件发送失败")
queue_email_for_retry()
except OSError:
# 文件系统可能空间不足
log_error("用户目录创建失败")
cleanup_partial_registration()
这些操作涉及的都是外部状态，它们的失败是不可预测的：
- 数据库连接可能在任何时候断开
- 邮件服务器可能突然变得不可用
- 文件系统可能在运行过程中空间耗尽
即使你提前做了检查，这些状态也可能在执行过程中发生变化。比如：
# 这样的检查是不可靠的
if database.is_connected(): # 检查时连接正常
database.query() # 执行时可能已经断开
这就是为什么我们需要异常处理 - 它不是用来处理程序逻辑错误的，而是用来应对那些我们无法控制的外部世界的变化。断言和异常处理各自处理不同类型的问题：断言确保程序的内部逻辑正确性，异常处理则管理外部交互时的不确定性。在实际开发中，我们需要同时使用这两种机制来构建健壮的系统。
