参考：

• 11 程序中的错误处理：错误返回码和异常捕捉 | 极客时间 (opens new window)
• 12 程序中的错误处理：异步编程以及我的最佳实践 | 极客时间 (opens new window)

1. 错误返回码和异常捕捉

今天讨论一下程序中的错误处理。处理错误的代码并不难写，但要把错误处理写好，并不是一件容易的事情。

1.1 传统的错误检查及问题

这一小节讲了 C 语言处理错误存在的问题。

处理错误最直接的方式是通过错误码，这也是传统的方式，在过程式语言中通常都是用这样的方式处理错误的。比如 C 语言，基本上是通过函数的返回值标识是否有错，然后通过全局的 errno 变量并配合一个 errstr 的数组来告诉你为什么出错。

为什么这么设计？这主要是一种妥协。因为像 open() 函数的返回值无论正确返回 FILE* 还是错误返回 NULL，都是有业务逻辑的返回值，这样会导致调用者并不知道是什么原因出错了，只能去检查 errno 来获得出错的原因并处理。

一般而言，这样的错误处理方式在大多数情况下是没什么问题的。但有一些例外情况，比如 atoi 函数：

int atoi(const char *str);

这个函数是把一个字符串转成整型。但问题是如果输入非法字符串，比如"ABC"，那么返回什么数都会产生歧义，比如返回 0 会与正常的字符串 "0" 产生歧义，因此这样就无法判断是否出错。也许你会想应该检查 errno，但不幸的是，C99 的说明书描述了这个函数不会设置 errno，当传入非法字符串时，行为是 undefined 的。

后来 libc 给了一个新函数：strtol()，这个函数在出错时会设置全局变量 errno：

long strtol(const char *restrict str, char **restrict endptr, int base);

于是，我们就可以这样使用：

long val = strtol(in_str, &endptr, 10);  //10的意思是10进制

//如果无法转换
if (endptr == str) {
    fprintf(stderr, "No digits were found\n");
    exit(EXIT_FAILURE);
}

//如果整型溢出了
if ((errno == ERANGE && (val == LONG_MAX || val == LONG_MIN)) {
    fprintf(stderr, "ERROR: number out of range for LONG\n");
    exit(EXIT_FAILURE);
 }

//如果是其它错误
if (errno != 0 && val == 0) {
    perror("strtol");
    exit(EXIT_FAILURE);
}

虽然，strtol() 函数解决了 atoi() 函数的问题，但是我们还是能感觉到不是很舒服和自然。因为这种用“返回值 + errno”的错误检查方式会有一些问题：

• 程序员一不小心就会忘记返回值的检查，从而造成代码的 Bug；
• 函数接口非常不纯洁，正常值和错误值混淆在一起，导致语义有问题。

所以，后来，有一些类库就开始区分这样的事情。比如，Windows 的系统调用开始使用 HRESULT 的返回来统一错误的返回值，这样可以明确函数调用时的返回值是成功还是错误。但这样一来，函数的 input 和 output 只能通过函数的参数来完成，于是出现了所谓的“入参”和“出参”这样的区别，这又使得接口参数的语义变得复杂。

1.2 多返回值

这一小节讲 Go 的多返回值处理错误的方式

于是，有一些语言通过多返回值来解决这个问题，比如 Go 语言。Go 语言的很多函数都会返回 result, err 两个值，于是：

• 参数上基本上就是入参，而返回接口把结果和错误分离，这样使得函数的接口语义清晰；
• 而且，Go 语言中的错误参数如果要忽略，需要显式地忽略，用 _ 这样的变量来忽略；
• 另外，因为返回的 error 是个接口（其中只有一个方法 Error()，返回一个 string ），所以你可以扩展自定义的错误处理。

比如下面这个 JSON 语法的错误：

type SyntaxError struct {
    msg    string // description of error
    Offset int64  // error occurred after reading Offset bytes
}

func (e *SyntaxError) Error() string { return e.msg }

在使用上会是这个样子：

if err := dec.Decode(&val); err != nil {
    if serr, ok := err.(*json.SyntaxError); ok {
        line, col := findLine(f, serr.Offset)
        return fmt.Errorf("%s:%d:%d: %v", f.Name(), line, col, err)
    }
    return err
}

多说一句，如果一个函数返回了多个不同类型的 error，你也可以使用下面这样的方式：

if err != nil {
  switch err.(type) {
    case *json.SyntaxError:
      ...
    case *ZeroDivisionError:
      ...
    case *NullPointerError:
      ...
    default:
      ...
  }
}

但 Go 写法有个问题是：if err != nil 这样的语句简直是写到吐，而且正常的逻辑代码会被大量的错误处理打得比较凌乱。

1.3 资源清理

1.3.1 C 的 go gail 模式

程序出错时需要对已分配的一些资源做清理，在传统的玩法下，每一步的错误都要去清理前面已分配好的资源。于是就出现了 goto fail 这样的错误处理模式。如下所示：

#define FREE(p) if(p) { \
                    free(p); \
                    p = NULL; \
                 }
main()
{
  char *fname=NULL, *lname=NULL, *mname=NULL;
  fname = ( char* ) calloc ( 20, sizeof(char) );
  if ( fname == NULL ){
      goto fail;
  }
  lname = ( char* ) calloc ( 20, sizeof(char) );
  if ( lname == NULL ){
      goto fail;
  }
  mname = ( char* ) calloc ( 20, sizeof(char) );
  if ( mname == NULL ){
      goto fail;
  }
    
  ......
 
    
fail:
  FREE(fname);
  FREE(lname);
  FREE(mname);
  ReportError(ERR_NO_MEMORY);
}

这样的处理方式虽然可以，但是会有潜在的问题：你不能在中间的代码中有 return 语句，因为你需要清理资源。在维护这样的代码时需要格外小心，因为一不注意就会导致代码有资源泄漏的问题。

1.3.2 C++ 的 RAII

于是，C++ 的 RAII（Resource Acquisition Is Initialization）机制使用面向对象的特性可以容易地处理这个事情。RAII 是 C++ 类的机制，在构造函数中分配资源，在析构函数中释放资源。

先来看个不好的示例：

std::mutex m;
 
void bad() 
{
    m.lock();                    // 请求互斥
    f();                         // 若f()抛异常，则互斥绝不被释放
    if(!everything_ok()) return; // 提早返回，互斥绝不被释放
    m.unlock();                  // 若bad()抵达此语句，互斥才被释放
}

上面这个例子，在函数的第三条语句提前返回了，直接导致 m.unlock() 没有被调用，这样会引起死锁问题。我们来看一下用 RAII 的方式是怎样解决这个问题的。

//首先，先声明一个RAII类，注意其中的构造函数和析构函数
class LockGuard {
public:
  LockGuard(std::mutex &m):_m(m) { m.lock(); }
  ~LockGuard() { m. unlock(); }
private:
  std::mutex& _m;
}


//然后，我们来看一下，怎样使用的
void good()
{
  LockGuard lg(m);           // RAII类：构造时，互斥量请求加锁
  f();                             // 若f()抛异常，则释放互斥
  if(!everything_ok()) return;     // 提早返回，LockGuard析构时，互斥量被释放
}                                    // 若good()正常返回，则释放互斥

1.3.3 Go 的 defer 关键字

在 Go 语言中，使用 defer 关键字也可以做到这样的效果。参看下面的示例：

func Close(c io.Closer) {
  err := c.Close()
  if err != nil {
    log.Fatal(err)
  }
}

func main() {
  r, err := Open("a")
  if err != nil {
    log.Fatalf("error opening 'a'\n")
  }
  defer Close(r) // 使用defer关键字在函数退出时关闭文件。

  r, err = Open("b")
  if err != nil {
    log.Fatalf("error opening 'b'\n")
  }
  defer Close(r) // 使用defer关键字在函数退出时关闭文件。
}

上面讲了三种语言的资源处理方式，在设计上有不同的权衡。

1.4 异常捕捉处理

这一节讨论了 Java 中 try-catch-finally 这种编程模式。

上面，我们讲了错误检查和程序出错后对资源的清理这两个事。能把这个事做得比较好的其实是 try-catch-finally 这个编程模式。

try {
  ... // 正常的业务代码
} catch (Exception1 e) {
  ... // 处理异常 Exception1 的代码
} catch (Exception2 e) {
  ... // 处理异常 Exception2 的代码
} finally {
  ... // 资源清理的代码
}

把正常的代码、错误处理的代码、资源清理的代码分门别类，看上去非常干净。这种异常处理方式有如下一些好处：

• 函数接口在 input（参数）和 output（返回值）以及错误处理的语义是比较清楚的。
• 正常逻辑的代码可以与错误处理和资源清理的代码分开，提高了代码的可读性。
• 异常不能被忽略（如果要忽略也需要 catch 住，这是显式忽略）。
• 在面向对象的语言中（如 Java），异常是个对象，所以，可以实现多态式的 catch。

与状态返回码相比，异常捕捉有一个显著的好处是，函数可以嵌套调用，或是链式调用：

// 嵌套调用
int x = add(a, div(b,c));

// 链式调用
Pizza p = PizzaBuilder().SetSize(sz) .SetPrice(p)...;

当然，你可能会觉得异常捕捉对程序的性能是有影响的，这句话也对也不对。原因是这样的：

• 异常捕捉的确是对性能有影响的，那是因为一旦异常被抛出，函数也就跟着 return 了。而程序在执行时需要处理函数栈的上下文，这会导致性能变得很慢，尤其是函数栈比较深的时候。
• 但从另一方面来说，异常的抛出基本上表明程序的错误。程序在绝大多数情况下，应该是在没有异常的情况下运行的，所以，有异常的情况应该是少数的情况，不会影响正常处理的性能问题。

总体而言，我还是觉得 try-catch-finally 这样的方式是很不错的。而且这个方式比返回错误码在诸多方面都更好。

但是，try-catch-finally 有个致命的问题，那就是在异步运行的世界里的问题。try 语句块里的函数运行在另外一个线程中，其中抛出的异常无法在调用者的这个线程中被捕捉。这个问题就比较大了。

1.5 错误返回码 VS 异常捕捉

是返回错误状态，还是用异常捕捉的方式处理错误，可能是一个很容易引发争论的问题。我觉得，应该从场景上来讨论这个事才是正确的姿势。

要讨论场景，我们需要先把要处理的错误分好类别，这样有利于简化问题。错误其实是很多的，不同的错误需要有不同的处理方式。但错误处理是有一些通用规则的。为了讲清楚这个事，我们需要把错误来分个类：

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

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

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

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

比如，如果你的函数参数传入的对象不应该是一个 null 对象，那么，一旦传入 null 对象后，函数就可以抛异常，因为我们并不期望总是会发生这样的事。

而对于一个需要检查用户输入信息是否正确的事，比如：电子邮箱的格式，我们用返回码可能会好一些。所以，对于上面三种错误的类型来说，程序中的错误，可能用异常捕捉会比较合适；用户的错误，用返回码比较合适；而资源类的错误，要分情况，是用异常捕捉还是用返回值，要看这事是不应该出现的，还是经常出现的。

当然，这只是一个大致的实践原则，并不代表所有的事都需要符合这个原则。除了用错误的分类来判断用返回码还是用异常捕捉之外，我们还要从程序设计的角度来考虑使用哪种方式好。因为异常捕捉在编程上的好处比函数返回值好很多，所以很多使用异常捕捉的代码会更易读也更健壮一些。而返回码容易被忽略，所以，使用返回码的代码需要做好测试才能得到更好的软件质量。

不过，在某些情况下，你只能使用其中的一个，比如：

• 在 C++ 重载操作符的情况下，你就很难使用错误返回码，只能抛异常；
• 异常捕捉只能在同步的情况下使用，在异步模式下，抛异常这事就不行了，需要通过检查子进程退出码或是回调函数来解决；
• 在分布式的情况下，调用远程服务只能看错误返回码，比如 HTTP 的返回码。

所以，在大多数情况下，我们会混用这两种报错的方式，有时候，我们还会把异常转成错误码（比如 HTTP 的 RESTful API），也会把错误码转成异常（比如对系统调用的错误）。

所以，不同的错误类型再加上不同的错误处理会导致我们代码组织层面上的不同，从而会让我们使用不同的方式。也就是说，使用错误码还是异常捕捉主要还是看我们的错误处理流程以及代码组织怎么写会更清楚。

以上我们所讨论的经验仅在同步编程世界中适用。因为在异步编程世界里，被调用的函数是被放到另外一个线程里运行的，所以本文中的两位主角，不管是错误返回码，还是异常捕捉，都难以发挥其威力。

2. 异步编程以及我的最佳实践

这一部分接着讲：异步编程世界里的错误处理方法，以及我在实战中总结出来的错误处理最佳实践。

2.1 异步编程世界里的错误处理

在异步编程的世界里，因为被调用的函数是被放到了另外一个线程里运行，这将导致：

• 无法使用返回码。因为函数在“被”异步运行中，所谓的返回只是把处理权交给下一条指令，而不是把函数运行完的结果返回。所以，函数返回的语义完全变了，返回码也没有用了。
• 无法使用抛异常的方式。因为除了上述的函数立马返回的原因之外，抛出的异常也在另外一个线程中，不同线程中的栈是完全不一样的，所以主线程的 catch 完全看不到另外一个线程中的异常。

对此，在异步编程的世界里，我们也会有好几种处理错误的方法，最常用的就是 callback 方式。在做异步请求的时候，注册几个 OnSuccess()、 OnFailure() 这样的函数，让在另一个线程中运行的异步代码回调过来。

2.2 JavaScript 中异步编程的错误处理

比如，下面这个 JavaScript 示例：

function successCallback(result) {
  console.log("It succeeded with " + result);
}

function failureCallback(error) {
  console.log("It failed with " + error);
}

doSomething(successCallback, failureCallback);

出错的语义从返回码、异常捕捉到了直接耦合错误出处函数的样子，挺好的。

但是， 如果我们需要把几个异步函数顺序执行的话，就会出现所谓的 Callback Hell 的问题：

doSomething(function(result) {
  doSomethingElse(result, function(newResult) {
    doThirdThing(newResult, function(finalResult) {
      console.log('Got the final result: ' + finalResult);
    }, failureCallback);
  }, failureCallback);
}, failureCallback);

而这样层层嵌套中需要注册的错误处理函数也有可能是完全不一样的，而且会导致代码非常混乱，难以阅读和维护。

所以，一般来说，在异步编程的实践里，我们会用 Promise 模式来处理：

doSomething()
.then(result => doSomethingElse(result))
.then(newResult => doThirdThing(newResult))
.then(finalResult => {
  console.log(`Got the final result: ${finalResult}`);
}).catch(failureCallback);

上面代码中的 then() 和 catch() 方法就是 Promise 对象的方法，then()方法可以把各个异步的函数给串联起来，而 catch() 方法则是出错的处理。

看到上面的那个级联式的调用方式，这就要我们的 doSomething() 函数返回 Promise 对象，下面是这个函数的相关代码示例：

function doSomething() {
  let promise = new Promise();
  let xhr = new XMLHttpRequest();
  xhr.open('GET', 'http://coolshell.cn/....', true);

  xhr.onload = function (e) {
        if (this.status === 200) {
            results = JSON.parse(this.responseText);
            promise.resolve(results); //成功时，调用resolve()方法
        }
    };

  xhr.onerror = function (e) {
      promise.reject(e); //失败时，调用reject()方法
  };

  xhr.send();
  return promise;
}

• 成功了就调用 Promise.resolve() 方法，这样 Promise 对象会继续调用下一个 then()
• 出错了就调用 Promise.reject() 方法，这样就会忽略后面的 then() 直到 catch() 方法

我们可以看到 Promise.reject() 就像是抛异常一样。这个编程模式让我们的代码组织方便了很多。另外，多说一句，Promise 还可以同时等待两个不同的异步方法。比如下面的代码所展示的方式：

promise1 = doSomething();
promise2 = doSomethingElse();
Promise.when(promise1, promise2).then( function (result1, result2) {
  ... //处理 result1 和 result2 的代码
}, handleError);

在 ECMAScript 2017 的标准中，我们可以使用 async/await 这两个关键字来取代 Promise 对象，这样可以让我们的代码更易读：

async function foo() {
  try {
    let result = await doSomething();
    let newResult = await doSomethingElse(result);
    let finalResult = await doThirdThing(newResult);
    console.log(`Got the final result: ${finalResult}`);
  } catch(error) {
    failureCallback(error);
  }
}

如果在函数定义之前使用了 async 关键字，就可以在函数内使用 await。 当在 await 某个 Promise 时，函数暂停执行，直至该 Promise 产生结果，并且暂停不会阻塞主线程。 如果 Promise resolve，则会返回值。 如果 Promise reject，则会抛出拒绝的值。

而我们的异步代码完全可以放在一个 try - catch 语句块内，在有语言支持了以后，我们又可以使用 try-catch 语句块了。

下面我们来看一下 pipeline 的代码。所谓 pipeline 就是把一串函数给编排起来，从而形成更为强大的功能。这个玩法是函数式编程中经常用到的方法。比如，下面这个 pipeline 的代码（注意，其上使用了 reduce() (opens new window) 函数）：

[func1, func2].reduce((p, f) => p.then(f), Promise.resolve());

其等同于：

Promise.resolve().then(func1).then(func2);

我们可以抽象成：

let applyAsync = (acc, val) => acc.then(val);
let composeAsync = (...funcs) => x => funcs.reduce(applyAsync, Promise.resolve(x));

于是，可以这样使用：

let transformData = composeAsync(func1, asyncFunc1, asyncFunc2, func2);
transformData(data);

但是，在 ECMAScript 2017 的 async/await 语法糖下，这事儿就变得更简单了：

for (let f of [func1, func2]) {
  await f();
}

2.3 Java 中异步编程的 Promise 模式

在 Java 中，在 JDK 1.8 里也引入了类似 JavaScript 的玩法 —— CompletableFuture。这个类提供了大量的异步编程中 Promise 的各种方式。下面我列举几个。

链式处理：

CompletableFuture.supplyAsync(this::findReceiver)
                 .thenApply(this::sendMsg)
                 .thenAccept(this::notify);

上面的这个链式处理和 JavaScript 中的then()方法很像，其中的：

• supplyAsync() 表示执行一个异步方法
• thenApply() 表示执行成功后再串联另外一个异步方法
• 最后 thenAccept() 来处理最终结果

下面这个例子是要合并两个异步函数的结果：

String result = CompletableFuture.supplyAsync(() -> {
         return "hello";
     }).thenCombine(CompletableFuture.supplyAsync(() -> {
         return "world";
     }), (s1, s2) -> s1 + " " + s2).join());
System.out.println(result);

接下来，我们再来看一下，Java 这个类相关的异常处理：

CompletableFuture.supplyAsync(Integer::parseInt) //输入: "ILLEGAL"
           .thenApply(r -> r * 2 * Math.PI)
           .thenApply(s -> "apply>> " + s)
           .exceptionally(ex -> "Error: " + ex.getMessage());

我们要注意到上面代码里的 exceptionally() 方法，这个和 JavaScript Promise 中的 catch() 方法相似。

运行上面的代码，会出现如下输出：

Error: java.lang.NumberFormatException: For input string: "ILLEGAL"

也可以这样：

CompletableFuture.supplyAsync(Integer::parseInt) // 输入: "ILLEGAL"
         .thenApply(r -> r * 2 * Math.PI)
         .thenApply(s -> "apply>> " + s)
         .handle((result, ex) -> {
           if (result != null) {
             return result;
           } else {
             return "Error handling: " + ex.getMessage();
           }
         });

上面代码中，你可以看到，其使用了 handle() 方法来处理最终的结果，其中包含了异步函数中的错误处理。

2.4 Golang 的 Promise

在 Go 语言中，如果你想实现一个简单的 Promise 模式，也是可以的。下面的代码纯属示例，只为说明问题。如果你想要更好的代码，可以上 GitHub 上搜一下 Go 语言 Promise 的相关代码库。

首先，先声明一个结构体。其中有三个成员：第一个 wg 用于多线程同步；第二个 res 用于存放执行结果；第三个 err 用于存放相关的错误。

type Promise struct {
  wg  sync.WaitGroup
  res string
  err error
}

然后，定义一个初始函数，来初始化 Promise 对象。其中可以看到，需要把一个函数 f() 传进来，然后调用 wg.Add(1) 对 waitGroup 做加一操作，新开一个 Goroutine 通过异步去执行用户传入的函数 f() ，然后记录这个函数的成功或错误，并把 waitGroup 做减一操作。

func NewPromise(f func() (string, error)) *Promise {
  p := &Promise{}
  p.wg.Add(1)
  go func() {
    p.res, p.err = f()
    p.wg.Done()
  }()
  return p
}

然后，我们需要定义 Promise 的 Then 方法。其中需要传入一个函数，以及一个错误处理的函数。并且调用 wg.Wait() 方法来阻塞（因为之前被 wg.Add(1))，一旦上一个方法被调用了 wg.Done()，这个 Then 方法就会被唤醒。唤醒的第一件事是，检查一下之前的方法有没有错误。如果有，那么就调用错误处理函数。如果之前成功了，就把之前的结果以参数的方式传入到下一个函数中。

func (p *Promise) Then(r func(string), e func(error)) (*Promise){
  go func() {
    p.wg.Wait()
    if p.err != nil {
      e(p.err)
      return 
    }
    r(p.res)
  }()
  return p
}

下面，我们定义一个用于测试的异步方法。这个方法很简单，就是在数数，然后，有一半的几率会出错。

func exampleTicker() (string, error) {
  for i := 0; i < 3; i++ {
    fmt.Println(i)
    <- time.Tick(time.Second * 1)
  }
  
  rand.Seed(time.Now().UTC().UnixNano())
  r := rand.Intn(100) % 2
  fmt.Println(r)
  if  r != 0 {
    return "hello, world", nil
  } else {
    return "", fmt.Errorf("error")
  }
}

下面，我们来看看我们实现的 Go 语言 Promise 是怎么使用的：

func main() {
  doneChan := make(chan int)
  
  var p = NewPromise(exampleTicker)
  p.Then(func(result string) {
      		fmt.Println(result);
      		doneChan <- 1 
  		}, 
        func(err error) {
            fmt.Println(err);
            doneChan <-1
        }
  )
  <- doneChan
}

当然，如果你需要更好的 Go 语言 Promise，可以到 GitHub 上找，上面好些代码都是实现得很不错的。上面的这个示例，实现得比较简陋，仅仅是为了说明问题。

3. 错误处理的最佳实践

下面是我个人总结的几个错误处理的最佳实践。

• 统一分类的错误字典。无论你是使用错误码还是异常捕捉，都需要认真并统一地做好错误的分类。最好是在一个地方定义相关的错误。比如，HTTP 的 4XX 表示客户端有问题，5XX 则表示服务端有问题。也就是说，你要建立一个错误字典。
• 同类错误的定义最好是可以扩展的。这一点非常重要，而对于这一点，通过面向对象的继承或是像 Go 语言那样的接口多态可以很好地做到。这样可以方便地重用已有的代码。
• 定义错误的严重程度。比如，Fatal 表示重大错误，Error 表示资源或需求得不到满足，Warning 表示并不一定是个错误但还是需要引起注意，Info 表示不是错误只是一个信息，Debug 表示这是给内部开发人员用于调试程序的。
• 错误日志的输出最好使用错误码，而不是错误信息。打印错误日志的时候，应该使用统一的格式。但最好不要用错误信息，而应使用相应的错误码，错误码不一定是数字，也可以是一个能从错误字典里找到的一个唯一的可以让人读懂的关键字。这样，会非常有利于日志分析软件进行自动化监控，而不是要从错误信息中做语义分析。比如：HTTP 的日志中就会有 HTTP 的返回码，如：404。但我更推荐使用像 PageNotFound 这样的标识，这样人和机器都很容易处理。
• 忽略错误最好有日志。不然会给维护带来很大的麻烦。
• 对于同一个地方不停的报错，最好不要都打到日志里。不然这样会导致其它日志被淹没了，也会导致日志文件太大。最好的实践是，打出一个错误以及出现的次数。
• 不要用错误处理逻辑来处理业务逻辑。也就是说，不要使用异常捕捉这样的方式来处理业务逻辑，而是应该用条件判断。如果一个逻辑控制可以用 if - else 清楚地表达，那就不建议使用异常方式处理。异常捕捉是用来处理不期望发生的事情，而错误码则用来处理可能会发生的事。
• 对于同类的错误处理，用一样的模式。比如，对于null对象的错误，要么都用返回 null，加上条件检查的模式，要么都用抛 NullPointerException 的方式处理。不要混用，这样有助于代码规范。
• 尽可能在错误发生的地方处理错误。因为这样会让调用者变得更简单。
• 向上尽可能地返回原始的错误。如果一定要把错误返回到更高层去处理，那么，应该返回原始的错误，而不是重新发明一个错误。
• 处理错误时，总是要清理已分配的资源。这点非常关键，使用 RAII 技术，或是try-catch-finally，或是 Go 的 defer 都可以容易地做到。
• 不推荐在循环体里处理错误。这里说的是try-catch，绝大多数的情况你不需要这样做。最好把整个循环体外放在 try 语句块内，而在外面做 catch。
• 为你的错误定义提供清楚的文档以及每种错误的代码示例。如果你是做 RESTful API 方面的，使用 Swagger 会帮你很容易搞定这个事。
• 对于异步的方式，推荐使用 Promise 模式处理错误。对于这一点，JavaScript 中有很好的实践。
• 对于分布式的系统，推荐使用 APM 相关的软件。尤其是使用 Zipkin 这样的服务调用跟踪的分析来关联错误。