8

在我们公司，我们正在讨论在使用 Promise 时是否需要在 node.js 中出现未处理的异常时退出进程

两种思想流派一直在我脑海中萦绕

  • 当我们在 node.js 中使用 Promise 时，我们需要使用 process.exit(1)

  • 当我们使用 Promise 时，我们不需要使用 process.exit(1)

顺便说一句，我们计划使用 blubird 模块进行承诺。

https://www.npmjs.org/package/bluebird

我想知道在发生未处理的异常时是否有必要退出进程，因为在使用 Promise 时，我们会得到“finally”语句来清理资源

http://canop.org/blog/?p=516

此外，当涉及到 node.js 时，promise 可能无法自行处理的错误类型（如果有的话）我们可能需要通过

process.on("uncaughtException")
{
process.exit(1);
}
4

2 回答 2

6

Short answer, no.

Long answer:

When you call process.exit() you cause processing to stop. The exit event is fired, which is the last opportunity for any code to run, and the event loop is stopped. Shortly thereafter Node.js actually stops completely and returns the specified exit code. So process.exit() stops Node.js from doing anything tangible after that point and the application stops.

The problem

The problem is that process.exit() can be called by any part of the application at any time. There is nothing preventing a parser from calling it:

exports.parse = function(text) {

    if (canParse(text)) {
        return doTheParse(text);
    } else {
        console.error("Can't parse the text.");
        process.exit(1);
    }

};

So if the text can be parsed then it is, but otherwise an error is output to the console and process.exit(1) is called. That’s an awful lot of responsibility for a lowly parser.

Since any module can call process.exit(), that means any function call gone awry could decide to shut down the application. That’s not a good state to be in. There should be one area of an application that decides when and if to call process.exit() and what the exit code should be (that’s usually the application controller). Utilities and such should never use process.exit(), it’s way out of their realm of responsibility.

Anytime you’re thinking about using process.exit(), consider throw an error instead:

Throwing an error has a similar effect as calling process.exit() in that code execution in this function stops immediately. However, calling functions have the opportunity to catch the error and respond to it in a graceful manner. If there is no intervention up the call stack, then the uncaughtException event is fired on process. If there are no event handlers, then Node.js will fire the exit event and exit with a non-zero exit code just like when process.exit() is called; if there are event handlers, then it is up to you to manually call process.exit() to specify the exit code to use.

The key is that throwing an error gives the application an opportunity to catch the error and recover from it, which is almost always the desired case when dealing with module code.

source: here

于 2014-06-10T20:11:32.200 回答
3

.finally对资源管理不是很好：

  • 它可以被遗忘，只有仔细的审计才能找到被遗忘的清理
  • 它可以在更复杂的场景中巧妙地泄漏资源

这就是为什么 2.0 引入的原因using，几乎不可能忘记使用它，因为对资源的承诺实际上是一个只能与using.

因此，如果您使用 获取资源using，则无需从其中发生的错误中重新开始。

请注意，这不包括库中的错误，如果您使用的库会泄漏资源，那么您需要重新启动进程。例如，对于https://github.com/joyent/node/issues/7697，您无能为力（除了分叉节点并在核心中使用承诺，因此这种事情是不可能的：D）。

于 2014-06-11T07:16:46.697 回答