node.js - 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);
});

谁能解释为什么会这样，这是一个错误还是按预期工作？最新 Node 4.x 和 Node 6.x 中的行为相同。

谢谢!

Answer 1

概要

问题在于您在监听器回调中抛出了一个 Uncaught Error 。 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;

因为你的 throw 没有被捕获，所以 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;
}

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

在其他一些情况下， Node 会注意何时调用回调以及预先设置的内容。但这主要是为了允许回调进行一些替代清理等，如本 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 检查。但是:

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

• 它仍然会使套接字处于部分清理状态，这对于生命周期较长的程序而言并不好。

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