本文内容大部分来自 https://www.joyent.com/node-js/production/design/errors ,原文比较长,感觉也有点啰嗦,所以根据个人理解猜测梳理出本文,如果有错误欢迎指出,谢谢!
很多人其实不是很重视错误处理,但对于构建一个健壮的nodejs应用,错误处理是非常重要的一件事情,希望本文可以给你一些启发。
先抛出几个问题:
throw
、 callback(err, result)
、 Event Emitter
或者其他方式? Bad Request
、 Service Unavailable
try/catch
,还是 domains
或者其他方式?
关于 Error
、 throw
、 try...catch
的一些基础知识链接
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/throw https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/try...catch
node.js v7.2.0 domain
、 process
https://nodejs.org/api/domain.html
https://nodejs.org/api/process.html
verror模块: rich JavaScript errors https://github.com/joyent/node-verror
抛出错误的几种方式:
var myEmitter = new MyEmitter(); doSomeAsynchronousOperation(function (err) { if (err) throw (err); // 直接throw if (err) callback(err); // 使用callback,nodejs中常见的异步处理方式 myEmitter.emit('error', new Error('whoops!')); // error事件 });
捕获错误
try{ var result = JSON.parse(str); }catch(e){ // 捕获错误 }
一般来说,我们将错误简单的分为两种类型:操作错误、编码错误。
对于有经验的人来说,写代码的时候都会处理一些常见的操作错误,例如 JSON.parse
总是会和 try...catch
一起,例如网络故障、远程服务器返回500等。这些错误并非bug。
对于程序来说,另外一种错误属于编码错误,这是程序的bug,解决的方式应该是修改代码,避免发生。例如 read property of "undefined"
、调用一个异步函数但没有传入callback、函数参数预期是 Object
但是传了一个 String
等等。
人们在谈论错误时,总是将这两种错误混在一起,实际上这两种错误是完全不同的。例如 File not found
是一种操作错误,但这不能说明哪里出错了,这可能仅仅表示程序应该先创建文件。
有些时候,同一个问题可能会导致多种错误。例如nodejs应用因为一个变量undefined导致crash,这是编码错误,客户端则会接收到 ECONNRESET
错误,这属于操作错误,对于客户端来说应该可以预期到服务器的这个错误。
例如尝试打开一个log文件可能会导致 ENOENT ,那么创建这个文件即可。
最好的方式是立即crash。
这种错误是程序的bug,一般来说写再多的代码也避免不了。因为在node应用中,我们一般会监控挂掉的进程并自动重启,所以立即crash是比较好的方式。
调试这类问题的最佳方式,是在捕获到 uncaught exception
的时候,记录相关信息。
总之记住,server的代码错误(bug)传递到client时会成为一个操作错误,例如server捕获到 uncaught exception
则返回一个500,客户端来处理这个操作错误。
首先,最重要的是文档,描述这个函数做了些什么,接收什么类型的参数返回什么,可能会触发什么错误。
一些基本原则:
throw
。使用者使用 try...catch
即可捕获错误。 callback(err, result)
的方式。 EventEmitter
对象,代替使用 callback
。使用者可以监听 emitter
对象的 error
事件。 例如读取一个数据流,我们可能会同时使用 req.on('data')
、 req.on('error')
、 req.on('timeout')
。
所以,使用 throw
还是 callbacks
、 EventEmitter
,取决于:
此外,
callback
或 EventEmitter
),只使用一种方式传递错误,避免同时使用两种方式。这样的话,使用者就只需要使用一种方式来捕获错误,例如 try...catch
或者 callback
,不需要考虑更多的场景。 下面用一个特例来说明这一点:
// 异步函数,err是操作错误,使用callback传递 fs.stat('不存在的文件',function(err){}) // 异步函数,参数错误,会立即抛出异常 fs.stat(null,function(err){})
在上例的第二种情况,会立即返回 TypeError: path must be a string or Buffer
,也就是说内部使用了 throw
,这种情况是不是和上面提到的有矛盾?
其实并不是,第二种情况属于编码错误( fs.stat
只接收路径作为参数但我们给了他一个 null
),并不是操作错误。编码错误永远不应该被处理。
所以在使用 fs.stat
的时,使用者仍然只需要处理 callback
传递的错误,不需要使用 try...catch
。
这一点取决于函数申明的可以允许的类型,以及你如何来解释它们:
你必须决定限制类型的严格程度。
例如需要连接到一个服务器,函数接收一个ip地址作为参数,那么有几种做法:
这两种做法决定了同样的输入会导致编码错误或操作错误。对于大多数功能,我们强烈建议更严格,因为更宽松的限制会更容易导致使用错误以及浪费时间。
domain
和 process.on('uncaughtException')
?
操作错误一般都可以使用明确的机制来处理(根据具体的错误对应处理,使用 try...catch
、 callback
、 EventEmitter
等)。
domain和全局的异常捕获主要是为了发现和处理未预料到的编码错误。
必须明确几点:期待的参数、参数类型、额外约束(IP地址、QQ号码等)
如果任意一点不匹配,则立即抛出 throw
异常。
此外,还应该有:使用方可以预料到的操作错误、如何捕获这些错误、返回值。
所有的error都应该提供 name
和 message
属性,并且 stack
也应该准确可用。
name
属性来区分错误类型
例如 RangeError
、 TypeError
。 不要为每种错误取个名字,例如定义 InvalidHostnameError
、 InvalidIpAddressError
这种来表示具体的错误,对于这种错误可以统一用 InvalidArgumentError
表示错误类型,然后在详细描述里补充更多信息。
例如无法连接到服务器,可以增加一个 remoteIp
属性表示试图连接的ip。
如果函数调用顺序如下:funcA -> funcB -> funcC,funcC返回一个加载配置失败的错误,funcB连接服务器失败。
那么,在funcA中,更希望得到包含这2个错误的信息。所以在funcB中捕获到funcC的错误时,包装并传递这些错误是有价值的。
包装底层的错误信息时,尽可能保留原始的信息,除了名称 name
,但不要改写原始的error对象。
一个组合多个错误的示例:
myserver: failed to start up: failed to load configuration: failed to connect to database server: failed to connect to 127.0.0.1 port 1234: connect ECONNREFUSED
这里有一个库可以帮我们做这件事:
https://github.com/joyent/node-verror
throw
)或者异步一种方式。一般来说,在nodejs中,同步函数导致的操作错误是比较少见的,使用 try...catch
会很少,常见的是用户输入验证如JSON、解析等。 throw
)。 例如一些常见的属性名称:
localHostname、localIp、localPort、remoteHostname、remoteIp、remotePort、path、srcpath、dstpath、hostname、ip、propertyName、propertyValue、syscall、errno
try...catch
去捕获一个异步函数的错误,这样会什么也得不到。 throw
。