NodeJS：http.ClientRequest在特定场景中两次触发错误事件

考虑以下在nodejs中执行的javascript代码：

// create ClientRequest // port 55555 is not opened var req = require('http').request('http://localhost:55555', function() { console.log('should be never reached'); }); function cb() { throw new Error(); } req.on('error', function(e) { console.log(e); cb(); }); // exceptions handler process.on('uncaughtException', function() { console.log('exception caught. doing some async clean-up before exit...'); setTimeout(function() { console.log('exiting'); process.exit(1); }, 2000); }); // send request req.end(); 

预期产出：

 { Error: connect ECONNREFUSED 127.0.0.1:55555 at Object.exports._errnoException (util.js:1026:11) at exports._exceptionWithHostPort (util.js:1049:20) at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1081:14) code: 'ECONNREFUSED', errno: 'ECONNREFUSED', syscall: 'connect', address: '127.0.0.1', port: 55555 } exception caught. doing some async clean-up before exit... exiting 

实际产出：

 { Error: connect ECONNREFUSED 127.0.0.1:55555 at Object.exports._errnoException (util.js:1026:11) at exports._exceptionWithHostPort (util.js:1049:20) at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1081:14) code: 'ECONNREFUSED', errno: 'ECONNREFUSED', syscall: 'connect', address: '127.0.0.1', port: 55555 } exception caught. doing some async clean-up before exit... { Error: socket hang up at createHangUpError (_http_client.js:252:15) at Socket.socketCloseListener (_http_client.js:284:23) at emitOne (events.js:101:20) at Socket.emit (events.js:188:7) at TCP._handle.close [as _onclose] (net.js:492:12) code: 'ECONNRESET' } exception caught. doing some async clean-up before exit... exiting 

正如你所看到的，http.ClientRequest（或者可能是stream.Writable？）两次触发错误事件，首先使用ECONNREFUSED，并捕获exception之后，ECONNRESET。

如果我们使用nextTick或setTimeout在http.ClientRequesterror handling程序中asynchronous执行callback，则不会发生这种情况，例如，此更改会给出预期的行为：

 req.on('error', function(e) { console.log(e); process.nextTick(cb); }); 

任何人都可以解释为什么发生这种情况，如果这是一个错误或按预期工作？ 行为在最新的节点4.x和节点6.x中是相同的。

谢谢！

Answer 1

概要

麻烦的是，你正在抛出一个未被捕获的错误内部侦听器callback。 节点故意不处理意外的exception，所以结果是通常在这个错误之后运行的代码已经被跳过了，因为控制必须去适当的catch（在这种情况下，一直到你的未捕获的exception处理）。这会导致一些事情不会发生，但最值得注意的是， HTTPRequest并不知道，当它被调用回套接字closures时，它成功地发出了一个错误。

细节和参考

节点的一般理念不是捕捉意外抛出 ，节点将这种模式视为应该允许失败的程序员错误 。 （该文档没有明确说明事件监听器callback的API，但是也没有提供任何例子，在抛出exception的时候或者在streamAPI的开发者端处理发射器时考虑可能性的说明。

当你的exception传播到发射器，并且随后的监听器以及其余的对套接字的清除和标记不会发生时，导致ClientRequest认为它需要再次提供一个错误：

你的callback抛出的发射器之后是代码来抑制第二个错误：

 req.emit('error', err); // For Safety. Some additional errors might fire later on // and we need to make sure we don't double-fire the error event. req.socket._hadError = true; 

既然你的throw没有被捕获， 检查这个variables然后发现_hadError仍然_hadError设置：

 if (!req.res && !req.socket._hadError) { // If we don't have a response then we know that the socket // ended prematurely and we need to emit an error on the request. req.emit('error', createHangUpError()); req.socket._hadError = true; } 

如果将错误推送到另一个asynchronous块中，则不会阻止其余的套接字清除过程继续，因为在其他某个function堆栈中将发生exception。

在其他一些情况下，节点在调用callback的时候要小心，事先设置的是什么。 但是这个主要是为了允许callback来做一些备用的清理等等，正如在这个评论中看到的那样：

 we set destroyed to true before firing error callbacks in order to make it re-entrance safe in case Socket.prototype.destroy() is called within callbacks 

交换设置_hadError和发光的顺序会抑制你的这个第二个错误，似乎是安全的，因为这似乎是唯一的_hadError检查。 但：

• 如果将来使用这种方法来抑制更多的错误，那么会对在错误期间尝试探测连接状态的错误callback产生负面影响

• 它仍然是在一个部分清理状态，这是不适合较长时间的生活节目的sockets。

所以我通常会说最好不要在callback中直接抛出exception，除非你有一个不寻常的情况，即必须防止或者忽略正常的内部处理。