概要

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

概要

问题是你在侦听器回调中抛出了一个未被捕获的错误。节点故意不处理意外的异常，因此结果是通常在此错误之后运行的代码已被跳过，因为控件必须转到相应的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检查。但是：

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

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

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

1 个答案:

概要

详情及参考资料