Python 工匠：让函数返回结果的技巧_python调函数的结果

虽然我在这里鼓励使用异常，但“异常”总是会无法避免的让人 感到惊讶，所以，最好在函数文档里说明可能抛出的异常类型

异常不同于返回值，它在被捕获前会不断往调用栈上层汇报。所以 create_item 的一级调用方完全可以省略异常处理，交由上层处理。这个特点给了我们更多的灵活性，但同时也带来了更大的风险。

Hint：如何在编程语言里处理错误，是一个至今仍然存在争议的主题。比如像上面不推荐的多返回值方式，正是缺乏异常的 Go 语言中最核心的错误处理机制。另外，即使是异常机制本身，不同编程语言之间也存在着差别。

异常，或是不异常，都是由语言设计者进行多方取舍后的结果，更多时候不存在绝对性的优劣之分。但是，单就 Python 语言而言，使用异常来表达错误无疑是更符合 Python 哲学，更应该受到推崇的。

4. 谨慎使用 None 返回值

None 值通常被用来表示“某个应该存在但是缺失的东西”，它在 Python 里是独一无二的存在。很多编程语言里都有与 None 类似的设计，比如 Java 里的 null、Go 里的 nil 等。因为 None 所拥有的独特 虚无 气质，它经常被作为函数返回值使用。

当我们使用 None 作为函数返回值时，通常是下面 3 种情况。

1. 作为操作类函数的默认返回值

当某个操作类函数不需要任何返回值时，通常就会返回 None。同时，None 也是不带任何 return 语句函数的默认返回值。

对于这种函数，使用 None 是没有任何问题的，标准库里的 list.append()、 os.chdir() 均属此类。

2. 作为某些“意料之中”的可能没有的值

有一些函数，它们的目的通常是去尝试性的做某件事情。视情况不同，最终可能有结果，也可能没有结果。而对调用方来说，“没有结果”完全是意料之中的事情。对这类函数来说，使用 None 作为“没结果”时的返回值也是合理的。

在 Python 标准库里，正则表达式模块 re 下的 re.search、 re.match 函数均属于此类，这两个函数在可以找到匹配结果时返回 re.Match 对象，找不到时则返回 None。

3. 作为调用失败时代表“错误结果”的值

有时， None 也会经常被我们用来作为函数调用失败时的默认返回值，比如下面这个函数：

当 username 不合法时，函数 create_user_from_name 将会返回 None。但在这个场景下，这样做其实并不好。不过你也许会觉得这个函数完全合情合理，甚至你会觉得它和我们提到的上一个“没有结果”时的用法非常相似。那么如何区分这两种不同情形呢？关键在于：函数签名（名称与参数）与 None 返回值之间是否存在一种“意料之中”的暗示。

让我解释一下，每当你让函数返回 None 值时，请仔细阅读函数名，然后问自己一个问题：假如我是该函数的使用者，从这个名字来看，“拿不到任何结果”是否是该函数名称含义里的一部分？

分别用这两个函数来举例：

• re.search()：从函数名来看， search，代表着从目标字符串里去搜索匹配结果，而搜索行为，一向是可能有也可能没有结果的，所以该函数适合返回 None
• create_user_from_name()：从函数名来看，代表基于一个名字来构建用户，并不能读出一种 可能返回、可能不返回的含义。所以不适合返回 None

对于那些不能从函数名里读出 None 值暗示的函数来说，有两种修改方式。第一种，如果你坚持使用 None 返回值，那么请修改函数的名称。比如可以将函数 create_user_from_name() 改名为 create_user_or_none()。

第二种方式则更常见的多：用抛出异常（raise Exception）来代替 None 返回值。因为，如果返回不了正常结果并非函数意义里的一部分，这就代表着函数出现了“意料以外的状况”，而这正是 Exceptions 异常 所掌管的领域。

使用异常改写后的例子：

与 None 返回值相比，抛出异常除了拥有我们在上个场景提到的那些特点外，还有一个额外的优势：可以在异常信息里提供出现意料之外结果的原因，这是只返回一个 None 值做不到的。

5. 合理使用“空对象模式”

我在前面提到函数可以用 None 值或异常来返回错误结果，但这两种方式都有一个共同的缺点。那就是所有需要使用函数返回值的地方，都必须加上一个 if 或 try/except 防御语句，来判断结果是否正常。

让我们看一个可运行的完整示例：

在这个例子里，每当我们调用 Account.from_string 时，都必须使用 try/except 来捕获可能发生的异常。如果项目里需要调用很多次该函数，这部分工作就变得非常繁琐了。针对这种情况，可以使用“空对象模式（Null object pattern）”来改善这个控制流。

Martin Fowler 在他的经典著作《重构》 中用一个章节详细说明过这个模式。简单来说，就是使用一个符合正常结果接口的“空类型”来替代空值返回/抛出异常，以此来降低调用方处理结果的成本。

引入“空对象模式”后，上面的示例可以被修改成这样：

在新版代码里，我定义了 NullAccount 这个新类型，用来作为 from_string 失败时的错误结果返回。这样修改后的最大变化体现在 caculate_total_balance 部分：

调整之后，调用方不必再显式使用 try 语句来处理错误，而是可以假设 Account.from_string 函数总是会返回一个合法的 Account 对象，从而大大简化整个计算逻辑。

Hint：在 Python 世界里，“空对象模式”并不少见，比如大名鼎鼎的 Django 框架里的 AnonymousUser 就是一个典型的 null object。

6. 使用生成器函数代替返回列表

在函数里返回列表特别常见，通常，我们会先初始化一个列表 results=[]，然后在循环体内使用 results.append(item) 函数填充它，最后在函数的末尾返回。

对于这类模式，我们可以用生成器函数来简化它。粗暴点说，就是用 yielditem 替代 append 语句。使用生成器的函数通常更简洁、也更具通用性。

我在 系列第 4 篇文章“容器的门道” 里详细分析过这个模式，更多细节可以访问文章，搜索 “写扩展性更好的代码” 查看。

1. 限制递归的使用
2. 当函数返回自身调用时，也就是 递归 发生时。递归是一种在特定场景下非常有用的编程技巧，但坏消息是：Python 语言对递归支持的非常有限。

这份“有限的支持”体现在很多方面。首先，Python 语言不支持“尾递归优化”。另外 Python 对最大递归层级数也有着严格的限制。

所以我建议：尽量少写递归。如果你想用递归解决问题，先想想它是不是能方便的用循环来替代。如果答案是肯定的，那么就用循环来改写吧。如果迫不得已，一定需要使用递归时，请考虑下面几个点：

函数输入数据规模是否稳定，是否一定不会超过 sys.getrecursionlimit() 规定的最大层数限制

是否可以通过使用类似 functools.lru_cache 的缓存工具函数来降低递归层数

总结

在这篇文章中，我虚拟了一些与 Python 函数返回有关的场景，并针对每个场景提供了我的优化建议。最后再总结一下要点：

• 让函数拥有稳定的返回值，一个函数只做好一件事
• 使用 functools.partial 定义快捷函数
• 抛出异常也是返回结果的一种方式，使用它来替代返回错误信息
• 函数是否适合返回 None，由函数签名的“含义”所决定

一、Python所有方向的学习路线

Python所有方向的技术点做的整理，形成各个领域的知识点汇总，它的用处就在于，你可以按照下面的知识点去找对应的学习资源，保证自己学得较为全面。

二、Python必备开发工具

工具都帮大家整理好了，安装就可直接上手！

三、最新Python学习笔记

当我学到一定基础，有自己的理解能力的时候，会去阅读一些前辈整理的书籍或者手写的笔记资料，这些笔记详细记载了他们对一些技术点的理解，这些理解是比较独到，可以学到不一样的思路。

四、Python视频合集

观看全面零基础学习视频，看视频学习是最快捷也是最有效果的方式，跟着视频中老师的思路，从基础到深入，还是很容易入门的。

五、实战案例

纸上得来终觉浅，要学会跟着视频一起敲，要动手实操，才能将自己的所学运用到实际当中去，这时候可以搞点实战案例来学习。

六、面试宝典

简历模板

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里无偿获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
深入研究，那么很难做到真正的技术提升。**

需要这份系统化学习资料的朋友，可以戳这里无偿获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！