嗨，各位！今天咱们聊点儿稍微有点儿“刺激”的话题——在 Python 里，python怎么抛出异常？别一听“异常”俩字儿就皱眉头，觉得它是bug的同义词。有时候，抛出异常，恰恰是代码在跟你“说话”，告诉你它不爽了，它遇到了处理不了的情况，需要你这个老大来定夺。这可不是啥坏事儿，反而是一种强大的控制流程的手段，是让你的程序更健壮、更负责任的表现。
你想想，你写了个函数，说好要处理正整数，结果有人传进来个负数，甚至是个字符串！这时候你的函数怎么办？硬着头皮往下算？那肯定会出问题，而且出的问题还不一定在你这个函数里，可能会像瘟疫一样传染到别的地方，最终导致程序崩溃，让你一脸懵逼找半天bug。
所以，更好的做法是什么？当你的函数发现输入不对劲儿，或者执行过程中遇到了约定之外的情况，它就应该立刻“大喊一声”：“喂！情况不对！我处理不了了！”这个“大喊一声”，在 Python 里，就是抛出异常。
怎么“喊”呢？很简单，就用那个超级直白的关键词：raise。
raise 关键词：抛出异常的“发令枪”
没错，就是这么简单。你想抛啥异常，就在 raise 后面跟着异常的类型，就像这样：
python
if input_value < 0:
raise ValueError("输入值不能是负数，老兄！")
看，这行代码，当 input_value 小于零的时候，它就不跟你客气了，直接用 raise 抛出一个 ValueError。而且，你还可以在异常后面跟一个字符串，这串文字就是这个异常的“身份证”，说明了为啥它要出现。这非常重要，因为捕获到这个异常的代码，就能通过这个字符串知道到底发生了啥。你想想，一个异常飞出来了，上面啥信息都没有，谁知道它是迷路了还是饿了还是咋地了？所以，加个清晰明了的信息，是基本操作，而且是好操作。
Python 自带了各种各样的异常类型，就像一个大家族。有 ValueError（值错了），TypeError（类型错了），FileNotFoundError（文件找不着了），ZeroDivisionError（除以零了），IndexError（列表索引越界了）等等等等。用哪个？得看你遇到的是啥情况。比如，你期望用户输入一个数字，结果他给了个字母，那更像是 TypeError 或者 ValueError。你打开文件没找到，那肯定是 FileNotFoundError 没跑儿了。选择合适的异常类型，能让你的代码更规范，也更容易被别人（包括未来的你）理解。这就像生病了得找对科室看病一样，别头疼医脚。
啥时候需要自己“动手”抛异常？
这个问题问得好。啥时候需要我们手动 raise 呢？主要有这么几种情况：
-
参数校验不通过： 这是最常见的场景。你的函数对输入有明确要求，比如年龄必须是正整数，密码长度不能少于6位。如果输入不符合这些要求，继续下去肯定是错的，这时候就该果断抛出异常，告诉调用者：“你的输入不合格！”这比返回一个特殊值（比如
-1或None）要好得多。为啥？因为返回特殊值，调用者可能会忘记检查，结果把-1当成正常结果继续处理，埋下隐患。而异常呢？你不处理它，程序就停那儿了，想忽略都难。“`python
def calculate_age(year_of_birth):
if not isinstance(year_of_birth, int) or year_of_birth <= 0:
raise ValueError(“出生年份必须是大于零的整数！”)
current_year = 2023 # 假设年份
return current_year – year_of_birth错误的使用方式会抛出异常
calculate_age(“一九九零”) # 会抛出 TypeError 或 ValueError
calculate_age(-10) # 会抛出 ValueError
“`
看到了吧？这样写，函数的契约非常明确：只接受大于零的整数。不符合？对不起，请收下我的异常。
-
业务逻辑中遇到的异常情况： 你的程序在执行某个业务流程时，可能会遇到预期之外，但又不算是程序本身的bug的情况。比如，你正在处理一个订单，发现用户的账户余额不足。这时候，抛出一个自定义的异常（后面我们会聊到）可能比简单返回一个错误码更能清晰地表达“订单无法完成”这个状态。
-
模块或库的使用限制： 你写了一个模块或库给别人用。为了强制使用者按照你的设计来，你可以在某些不应该发生的情况下抛出异常。比如，某个方法必须在对象初始化后才能调用，如果用户在初始化前就调了，你就
raise一个异常告诉他“哥们儿，你操作顺序错了！” -
某些操作失败且无法恢复： 比如连接数据库失败，或者远程服务调用超时。如果这些失败是致命的，当前操作无法继续，并且没有合理的备用方案，那抛出异常让上层代码去决定怎么办，通常是最好的选择。
抛出哪些异常？内置的，还是自定义的？
Python 内置的异常类型已经非常丰富了，很多时候用它们就足够了。比如，输入类型错误用 TypeError，输入值不合理用 ValueError，资源找不到用 FileNotFoundError 或 ResourceWarning（如果问题没那么严重的话）。优先使用内置异常，因为它更符合 Python 社区的习惯，别人读你的代码更容易理解。
但是，有时候内置的异常类型不足以精确描述你的业务逻辑中出现的特定错误。比如，你想表达“用户余额不足”，用 ValueError 可能有点模糊，它可能表示任何值的问题。这时候，你就需要自定义异常了。
自定义异常非常简单，就是定义一个类，让它继承自 Exception 或其它的内置异常类。
“`python
class InsufficientFundsError(Exception):
“””自定义异常：余额不足”””
def init(self, balance, required):
self.balance = balance
self.required = required
super().init(f”余额不足。当前余额: {balance}, 需要: {required}”)
使用自定义异常
def process_payment(amount, account):
if account.balance < amount:
raise InsufficientFundsError(account.balance, amount)
# … 处理支付逻辑 …
“`
看，我们定义了一个 InsufficientFundsError 异常，它继承自 Exception。在它的 __init__ 方法里，我们不仅调用了父类的 __init__（这通常是个好习惯），还可以在异常对象里存储一些额外的信息（比如当前的余额和需要的金额），这样捕获这个异常的代码就能拿到更详细的错误上下文。
自定义异常的好处是：
- 语义清晰： 你一眼就知道这个异常代表什么意思。
- 易于捕获和处理： 捕获代码可以专门针对
InsufficientFundsError进行处理，而不是笼统地捕获所有Exception。 - 封装错误信息： 可以把与错误相关的上下文信息封装在异常对象里，方便调用者获取。
当然，也不是说一点小问题都要自定义一个异常。如果一个内置异常就能清楚表达问题，那就用内置的。自定义异常应该用在那些具有特定业务含义、需要单独处理或提供额外上下文的错误情况。别滥用，异常类太多了也不见得是好事儿。
抛出异常后会发生什么？
这是很多人刚接触异常处理时会困惑的地方。当你 raise 一个异常后，当前的函数执行会立即停止。异常会沿着调用栈向上“冒泡”，一层一层地往上传递，直到被某个 try...except 块捕获。
想象一下，函数 A 调用了函数 B，函数 B 调用了函数 C。如果在函数 C 里 raise 了异常：
- 函数 C 立即停止执行。
- 异常传递到函数 B。函数 B 如果没有
try...except捕获这个异常，它也会停止执行，异常继续往上传递。 - 异常传递到函数 A。如果函数 A 有
try...except捕获了这个异常，那么except块里的代码就会执行，处理这个异常，程序可以继续运行（在except块之后）。 - 如果函数 A 也没有捕获这个异常，异常就会一直传到程序的最顶层（也就是你运行脚本的地方）。如果在顶层也没有处理，程序就会终止，并打印出异常信息（也就是我们常说的 trace back）。
所以，抛出异常就像是程序发出的一个紧急信号。这个信号会一路向上，直到有人（一个 except 块）决定接收并处理它。
一些“高级”玩法和注意事项
-
抛出已经捕获的异常： 有时候，你捕获了一个异常，做了些处理（比如记录日志），然后你觉得这个异常还是应该继续往上传，让更上层的代码去处理。这时候，你可以只写一个
raise，不跟任何东西，它会重新抛出当前正在处理的那个异常。python
try:
# 可能会抛出异常的代码
pass
except Exception as e:
print(f"记录日志：发生了一个错误 - {e}")
# 重新抛出，让上层代码处理
raise -
异常链（Exception Chaining）： 在 Python 3 里，你可以使用
raise ... from ...的语法来表明当前抛出的异常是由另一个异常引起的。这在捕获了一个低层异常后，又想抛出一个更高级别的异常来描述问题时非常有用。它能保留原始异常的信息，方便调试。python
try:
# 尝试打开文件
open("non_existent_file.txt")
except FileNotFoundError as original_error:
# 包装成一个更高级别的应用错误
raise ApplicationError("无法加载配置文件") from original_error这样，当
ApplicationError被捕获时，你可以查看它的__cause__属性，找到最初的FileNotFoundError，追溯问题的根源。 -
不要滥用异常： 异常处理是有成本的，它会打断正常的程序流程，需要构建调用栈信息等等。所以，不要把异常当成常规的控制流程工具，比如用异常来跳出循环（虽然可以做到，但不推荐）。异常应该用于那些“不正常”、“意外”的情况。对于可以通过返回值或者简单的
if/else来处理的预期情况，就不要用异常了。比如，检查一个列表是不是空的，直接判断长度就行，没必要在列表空的时候抛个异常说“列表为空！”。 -
文档说明： 如果你的函数或者方法会抛出异常，一定要在文档字符串（docstring）里清楚地说明会抛出哪些异常，以及在什么条件下会抛出。这就像给你的代码写了个“使用说明”，告诉别人使用你的代码时可能遇到哪些“坑”，以及怎么应对。
总结一下（不写“总结”俩字儿哈）
在 Python 里，python怎么抛出异常，核心就是那个简洁有力的 raise 关键词。通过 raise 加上合适的异常类型（内置的或自定义的），你可以优雅地告诉程序的调用者：“我遇到麻烦了，请处理！” 合理地使用异常，不仅能让你的代码在遇到问题时不再“沉默”，而是能够清晰地发出信号，还能让你的程序结构更清晰，错误处理更集中，最终写出更健壮、更可靠的应用。
抛出异常不是制造问题，它是解决问题、管理错误的重要手段。学会它，用好它，你的 Python 代码会更专业，更让人放心。别怕用它，大胆地在你觉得“不对劲儿”的地方 raise 吧！
评论(0)