【问题标题】：NodeJS: http.ClientRequest fires error event twice in specific scenarioNodeJS：http.ClientRequest 在特定场景中两次触发错误事件
【发布时间】：2016-12-26 10:54:56
【问题描述】：

考虑以下在 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，然后在捕获异常后，ECONNRESET。

如果我们使用 nextTick 或 setTimeout 在 http.ClientRequest 错误处理程序中异步执行回调，则不会发生这种情况，例如此更改给出了预期的行为：

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

谁能解释为什么会发生这种情况以及这是一个错误还是按预期工作？最新节点 4.x 和节点 6.x 中的行为相同。

谢谢！

【问题讨论】：

标签： node.js http exception error-handling

【解决方案1】：

概要

问题在于您在侦听器回调中抛出了未捕获的错误。 Node 故意不处理意外异常，因此结果是通常在此错误之后运行的代码作为控制被跳过，必须转到适当的 catch（在这种情况下一直到您的未捕获异常处理。）这会导致一些事情不会发生，但最值得注意的是HTTPRequest 不知道它在被回调以关闭套接字时成功发出错误。

详细信息和参考

Node 的一般理念是 not to trap unexpected throws，并且 node 将此模式视为应允许发生故障的 programmer error。（文档没有明确说明事件侦听器回调的 API，但也没有提供引发异常的示例或说明在流 API 的开发者端处理发射器时考虑可能性的示例。）

当您的异常传播到发射器，并且后续的侦听器及其对套接字的其余清理和标记没有发生时，导致ClientRequest 认为它需要再次提供错误：

您的回调抛出的emitter 后面是抑制第二个错误的代码：

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;

由于您的投掷没有被捕获，因此该变量的 Check 找到 _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;
}

如果您将错误推送到另一个异步块中，那么您不会阻止套接字清理过程的其余部分继续进行，因为异常将在某些其他函数堆栈中发生。

在其他一些情况下，节点会小心它何时调用回调以及它预先设置的内容。但这主要是为了允许回调进行一些备用清理等，如comment 所示：

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 检查。但是：

如果这用于在未来抑制更多错误，那么这将对尝试在错误期间探测连接状态的错误回调产生负面影响
它仍然会使套接字处于部分清理状态，这对于寿命较长的程序来说并不好。

所以我通常会说最好不要直接在回调中抛出异常，除非您遇到异常情况，必须阻止或覆盖正常的内部处理。

【讨论】：