NodeJS:http.ClientRequest在特定方案中两次触发错误事件

Question

考虑遵循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中的行为相同.

谢谢!

Answer 1

概要

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

详细信息和参考

Node 的一般理念是不捕获意外的抛出，并且 node 将此模式视为应该允许达到失败的程序员错误。（该文档没有明确关于事件侦听器回调的 API，但也没有提供在流 API 的开发人员端处理发射器时抛出异常或考虑可能性的示例。）

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

您的回调抛出的发射器后跟用于抑制第二个错误的代码：

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 for this variable then finds_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;
}

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

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

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

• 如果这用于在将来抑制更多错误，那么这将对尝试在错误期间探测连接状态的错误回调产生负面影响

• 它仍然会使套接字处于部分清理状态，这对于寿命较长的程序来说并不好。

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