如何使用 node.js 中的堆栈跟踪来控制台记录错误？

Question

我一直在尝试调试我的节点应用程序以在我的日志中查找错误的来源，该错误仅显示为“Error: Can't set headers after they are sent”，没有任何跟踪信息或任何上下文。

碰巧，我想我现在已经解决了这个问题...我正在使用connect-timeout，并且我正在继续处理传递给异步网络操作的回调，该回调最终会尝试执行res.send()，尽管req.timedout 在网络运行期间被connect-timeout 设置为“true”。

但我仍然不明白为什么我的日志没有显示此错误的跟踪信息。在我的代码中返回错误的任何地方，我都会将其记录到控制台：

console.log(err);

如果err 对象中有可用的跟踪信息，并且这似乎放在err.stack 中，上述语句不应该转储err 的全部内容（包括err.stack) 到控制台日志？我的理解是，通过执行上述操作，我不会丢失任何信息，例如到：

console.log(err.stack);

但this one 之类的帖子似乎另有说明（尽管链接的帖子现已更新）。

我其实更进一步，添加一些相关的文字来帮助定位错误：

console.log('error in dodgyFunction:', err);

但尽管如此，我仍然只得到“Error: Can't set headers after they are sent”，没有任何我会说的上下文。这是因为此控制台错误消息是在外部库（如express）中输出的吗？我认为外部库应该将错误发送回主代码以进行相应处理？

编辑：这是我将错误和超时检查放在传递给异步操作的回调函数顶部的示例：

var execFile = require('child_process').execFile;
execFile('dodgycommand', options, function(error, stdout, stderr) {
    if (req.timedout) {
        console.log('timeout detected whilst running dodgycommand, so aborting...');
        return;
    }
    if (error) {
        console.log('error running dodgycommand:', error);
        res.sendStatus(400);
        return;
    }

    // ... it's safe to continue ...

}

我基本上始终遵循相同的模式。

Answer 1

我刚刚弄清楚发生了什么，我希望这将有助于其他人避免这个初学者的错误。

对于我的一些错误记录，我使用了类似以下的内容，使用字符串连接来构造错误消息：

console.log('error in function abc: ' + err + ' whilst doing xyz');

而在其他地方我使用类似以下的东西，只是将错误消息的片段作为单独的参数传递给console.log：

console.log('error in function xyz:', err, 'whilst doing abc');

我现在看到这些给出了不同的结果！

前者必须对err进行字符串化，以便与消息的其他部分连接，而根据this，这样做只使用消息部分。

但是，在后一种形式中，err 对象必须由console.log 处理，并作为一个整体转储。

这解释了为什么有时我没有看到错误的全部内容，正如我所期望的那样，而其他时候我却看到了。

至于其他库放在那里的控制台日志消息，要检查的另一件事是您没有在日志查看器中过滤掉日志消息的“堆栈”部分......原来我是 （为了节省日志配额......我正在使用 papertrail）...... d'oh。我是通过过滤掉以____at（四个空格后跟'at'）开头的所有行来做到这一点的，例如____at Request.self.callback。

Answer 2

我现在已经安装了n，我可以确认以下内容：

节点 4.0.0

使用console.log(err) 仅打印错误消息。

节点 7.7.0（最新）

使用console.log(err) 会打印错误消息和完整堆栈。

我已确认此行为在版本 6.0.0 上发生了变化。因此，如果您使用旧版本，我建议您更新 Node.js 或使用 console.log(err.stack) 来打印完整堆栈。

Answer 3

您的模式看起来很普遍，但我会说我通常不喜欢它，稍后再详细说明。

至于您的主要问题，根据您提供的内容很难回答。如果您显示实际代码而不是“我通常遵循这种模式”，它可能会有所帮助。但是同样有可能错误被抛出到你没有预料到的地方，所以你的console.log 根本没有被调用。

看来您正在寻找最佳做法，所以我将给您我认为迄今为止我发现的最佳做法。

首先，不要使用console.log 进行日志记录。这并不可怕，但你可以做得更好，更好。我最喜欢的是使用morgan 作为中间件来记录请求信息，debug 用于应用程序记录。

使用debug，您可以设置自定义日志级别，并以您想要的任何粒度级别收听您想要的任何级别。这一切都通过设置 DEBUG 环境变量来控制，在生产中，您可以重定向到文件或您想要的任何其他目标。此外，许多节点模块（包括 Express 和 Connect）在后台使用 Debug 作为其记录器，因此通过调整您的 DEBUG 变量，您可以根据需要查看尽可能多或少的内部日志记录。 非常有助于找出哪里出了问题。

其次，正如我所说，在路由方面，我根本不使用您拥有的模式。我发现如果我不小心，很容易不小心多次发送标头，所以我的中间件总是返回next()，并且响应只在我可以肯定只触发一次的实际处理程序中发送。当涉及到错误时，我总是传递next(e)，然后我可以在错误处理函数中处理它。我还创建了 praeter 库来提供基于 Web 状态代码和通用错误处理程序的标准错误。

模式看起来像这样：

// middleware function to put something on the request object
app.use((req, res, next) => {
  MyModel.doSomething((e, thing) => {
    if (e) return next(e);
    if (!thing) return next(new NotFound()); // NotFound is an error in praeter that equates to a 404. 
    req.thing = thing;
    return next();
  });
});

后来

// log in here is a reference to my debug configured log object
app.use((err, req, res, next) => {
  log.error(err);
  log.error(err.stack);
  return res.status(err.statusCode || 500).send(err.message)
});

请注意，这是一个最终错误处理程序的简单示例。我经常有其中的几个，我可能会根据应用程序的需要以不同的方式处理不同的错误代码。