一般而言，对于错误处理，可以将其进行异常捕获（try-catch）和通过返回错误码这两种方式。

有人说，对于一些偏底层的错误，比如：空指针、内存不足等，可以使用返回错误状态码的方式，而对于一些上层的业务逻辑方面的错误，可以使用异常捕捉。这么说有一定道理，因为偏底层的函数可能用得更多一些。但是我并不这么认为。

因为，错误其实是很多的，不同的错误需要有不同的处理方式。但错误处理是有一些通用的规则的。为了讲清这个事，我们需要把错误来分个类。我个人觉得错误可以被分成三个大类。

• 资源的错误。当我们的代码去请求一些资源时导致的错误，比如打开一个没有权限的文件，写文件时出现的写错误，发送文件到网络端发现网络故障的错误，等等。这一类错误属于程序运行环境的问题。对于这类错误，有的，我们可以处理，有的我们则无法处理。比如，内存耗尽、栈溢出或是一些程序运行时关键性资源不能满足时，我们只能停止运行，甚至退出整个程序。
• 程序的错误。比如：空指针、非法参数等。这类是我们自己程序的错误，我们要记录下来，写入日志，最好触发监控系统报警。
• 用户的错误。比如：Bad Request、Bad Format 等这类由用户的不合法输入带来的错误。这类错误基本上是在用户的 API 层上出现的问题。比如，解析一个 XML 或 JSon 文件，或是用户输入的字段不合法之类的。对于这类问题，我们需要向用户端报错，让用户自己处理修正他们的输入或操作。然后，我们正常执行，但是需要做统计，统计相应的错误率，这样有利我们改善软件或是侦测是否有恶意的用户请求。

我们可以看到，这三类错误中，有些是我们希望杜绝发生的，比如程序的 Bug，有些则是我们杜绝不了的，比如用户的输入。而对于程序运行环境中的一些错误，则是我们希望可以恢复的。也就是说，我们希望可以通过重试或是妥协的方式来解决这些环境的问题，比如重建网络连接，重新打开一个新的文件。

所以，是不是我们可以这样来在逻辑上分类：

• 对于我们并不期望会发生的事，我们可以使用异常捕捉；
• 对于我们觉得可能会发生的事，使用返回码。

比如，如果你的函数参数传入的对象不是一个 null 对象，那么，一旦传入后，可以抛异常，因为我们并不期望总是会发生这样的事。而对于一个需要检查用户输入信息是否正确的事，比如：电子邮箱的格式，我们用返回码可能会好一些。所以，对于上面三种错误的种类来说，程序中的错误，可能用异常捕捉会比较合适；用户的错误，用返回码比较合适；而资源类的错误，要分情况，是用异常捕捉还是用返回值，要看这事是不应该出现的，还是经常出现的。

当然，这只是一个大致的实践原则，并不代表所有的事都需要符合这个原则。

除了用错误的分类来判断是否用返回码还是用异常捕捉之外，我们还要从程序设计的角度来考虑哪种情况下使用异常捕捉更好，哪种情况下使用返回码更好。因为异常捕捉在编程上的好处比函数返回值好很多，所以很多使用异常捕捉的代码会更易读也更健壮一些。而返回码容易被忽略，所以，使用返回码的代码需要做良好的测试才能得到更好的质量。

不过，我们也要知道，在某些情况下，你只能使用其中的一个，比如：

• 在 C++ 重载操作符的情况下，你就很难使用错误返回码，只能抛异常；
• 异常捕捉只能在同步的情况下使用，在异步模式下，抛异常这事就不行了，需要通过检查子进程退出码或是回调函数来解决；
• 在分布式的情况下，调用远程服务只能看错误返回码，比如 HTTP 的返回码。
  所以，在大多数情况下，我们会混用这两种报错的方式，有时候，我们还会把异常转成错误码（比如 HTTP 的 RESTful API），也会把错误码转成异常（比如对系统调用的错误）。

总之，“报错的类型” 和 “错误处理” 是紧密相关的，错误处理方法多种多样，而且会在不同的层面上处理错误。有些底层错误就需要自己处理掉（比如：底层模块会自动重建网络连接），而有一些错误需要更上层的业务逻辑来处理（比如：重建网络连接不成功后只能让上层业务来处理怎么办？降级使用本地缓存还是直接报错给用户，等等）。所以，不同的错误类型再加上不同的错误处理会导致我们代码组织层面上的不同，从而会让我们使用不同的方式（也就是说，使用错误码还是异常捕捉主要还是看我们我们的错误处理流程以及代码组织怎么写会更清楚）。

然而，这些知识和经验仅在同步编程世界中适用。因为在异步编程世界里，被调用的函数是被放到另外一个线程里运行的，所以本文中的两位主角，不管是错误返回码，还是异常捕捉，都难以发挥其威力。那么异步编程世界中是如何做错误处理的呢？