您可以捕获未捕获的异常，但它的用处有限。看见http://debuggable.com/posts/node-js-dealing-with-uncaught-exceptions:4c933d54-1428-434c-928d-4e1ecbd56cb

monit、forever或upstart可用于在节点进程崩溃时重新启动它。您最希望的是一个优雅的关闭（例如，将所有内存中的数据保存在未捕获的异常处理程序中）。

  getCountryRegionData: (countryName, stateName) => {
    let countryData, stateData

    try {
      countryData = countries.find(
        country => country.countryName === countryName
      )
    } catch (error) {
      console.log(error.message)
      return error.message
    }

    try {
      stateData = countryData.regions.find(state => state.name === stateName)
    } catch (error) {
      console.log(error.message)
      return error.message
    }

    return {
      countryName: countryData.countryName,
      countryCode: countryData.countryShortCode,
      stateName: stateData.name,
      stateCode: stateData.shortCode,
    }
  },

以下是关于这个主题的许多不同来源的摘要和策展，包括代码示例和所选博客文章的引用。最佳实践的完整列表可在此处找到

---

Node.JS错误处理的最佳实践

---

数字1：使用promise进行异步错误处理

TL；DR：以回调方式处理异步错误可能是通向地狱的最快方式（也就是末日金字塔）。你能给你的代码最好的礼物是使用一个信誉良好的promise库，它提供了很多简洁和熟悉的代码语法，比如try-catch

否则：Node.JS回调样式，函数（错误，响应），是一种很有希望的不可维护代码的方式，因为错误处理与随意代码、过度嵌套和笨拙的编码模式混合在一起

代码示例-良好

doWork()
.then(doWork)
.then(doError)
.then(doWork)
.catch(errorHandler)
.then(verify);

代码示例反模式–回调式错误处理

getData(someParameter, function(err, result){
    if(err != null)
      //do something like calling the given callback function and pass the error
    getMoreData(a, function(err, result){
          if(err != null)
            //do something like calling the given callback function and pass the error
        getMoreData(b, function(c){ 
                getMoreData(d, function(e){ 
                    ...
                });
            });
        });
    });
});

博客引用：“我们的承诺有问题”（来自博客pouchdb，关键词“节点承诺”排名第11）

“……事实上，回调做了更险恶的事情：它们剥夺了我们的堆栈，这在编程语言中通常是理所当然的。编写没有堆栈的代码就像驾驶没有刹车踏板的汽车：你不会意识到你有多么迫切需要它，直到你伸手去拿它，但它不在那里。承诺的全部目的是让我们重新获得语言基础。”异步时我们失去了：返回、抛出和堆栈。但你必须知道如何正确使用承诺，才能利用它们。"

---

数字2：仅使用内置Error对象

TL；DR：将抛出错误的代码视为字符串或自定义类型是很常见的，这会使错误处理逻辑和模块之间的互操作性变得复杂。无论您是拒绝承诺、抛出异常还是发出错误——使用Node.JS内置的error对象可以提高一致性并防止错误信息丢失

否则：在执行某个模块时，不确定返回的错误类型会导致很难推理和处理即将发生的异常。甚至值得一提的是，使用自定义类型来描述错误可能会导致丢失关键错误信息，如堆栈跟踪！

代码示例-正确执行

    //throwing an Error from typical function, whether sync or async
 if(!productToAdd)
 throw new Error("How can I add new product when no value provided?");

//'throwing' an Error from EventEmitter
const myEmitter = new MyEmitter();
myEmitter.emit('error', new Error('whoops!'));

//'throwing' an Error from a Promise
 return new promise(function (resolve, reject) {
 DAL.getProduct(productToAdd.id).then((existingProduct) =>{
 if(existingProduct != null)
 return reject(new Error("Why fooling us and trying to add an existing product?"));

代码示例反模式

//throwing a String lacks any stack trace information and other important properties
if(!productToAdd)
    throw ("How can I add new product when no value provided?");

博客引用：“字符串不是错误”（来自博客devthink，关键字“Node.JS错误对象”排名第6）

“…传递字符串而不是错误会降低模块之间的互操作性。它会破坏与API的合同，这些API可能正在执行错误实例检查，或者希望了解更多有关错误的信息。正如我们将看到的，错误对象在现代JavaScript引擎中除了保存传递给构造函数的消息之外，还有非常有趣的财产。”

---

数字3：区分操作和编程错误

TL；DR：操作错误（例如API接收到无效输入）是指完全理解错误影响并可以谨慎处理的已知情况。另一方面，程序员错误（例如，试图读取未定义的变量）是指未知的代码故障，导致应用程序正常重新启动

否则：您可能总是在出现错误时重新启动应用程序，但为什么要让约5000名在线用户因为一个小的和预测的错误（操作错误）而停机？相反的情况也不理想&当发生未知问题（程序员错误）时，保持应用程序运行可能会导致无法预测的行为。将两者区分开来，可以巧妙地采取行动，并根据给定的环境应用平衡的方法

代码示例-正确执行

    //throwing an Error from typical function, whether sync or async
 if(!productToAdd)
 throw new Error("How can I add new product when no value provided?");

//'throwing' an Error from EventEmitter
const myEmitter = new MyEmitter();
myEmitter.emit('error', new Error('whoops!'));

//'throwing' an Error from a Promise
 return new promise(function (resolve, reject) {
 DAL.getProduct(productToAdd.id).then((existingProduct) =>{
 if(existingProduct != null)
 return reject(new Error("Why fooling us and trying to add an existing product?"));

代码示例-将错误标记为可操作（可信）

//marking an error object as operational 
var myError = new Error("How can I add new product when no value provided?");
myError.isOperational = true;

//or if you're using some centralized error factory (see other examples at the bullet "Use only the built-in Error object")
function appError(commonType, description, isOperational) {
    Error.call(this);
    Error.captureStackTrace(this);
    this.commonType = commonType;
    this.description = description;
    this.isOperational = isOperational;
};

throw new appError(errorManagement.commonErrors.InvalidInput, "Describe here what happened", true);

//error handling code within middleware
process.on('uncaughtException', function(error) {
    if(!error.isOperational)
        process.exit(1);
});

博客语录：“否则你会冒国家的风险”（来自可调试的博客，关键字“Node.JS未捕获异常”排名第3）

“……就抛出在JavaScript中的工作原理而言，几乎没有任何方法可以安全地“从你停止的地方继续”，而不泄漏引用，或创建其他类型的未定义脆性状态。响应抛出错误的最安全方法是关闭进程。当然，在正常的web服务器中，您可能有许多连接处于打开状态，因为错误是由其他人触发的，所以突然关闭这些连接是不合理的。更好的方法是对触发错误的请求发送错误响应，同时让其他人在正常时间内完成，并停止侦听该工作人员中的新请求。”

---

数字4：通过中间件而不是在中间件内集中处理错误

TL；DR：错误处理逻辑（如发送给管理员的邮件和日志记录）应该封装在一个专用的集中对象中，当出现错误时，所有端点（如Express中间件、cron作业、单元测试）都会调用该对象。

否则：不在一个地方处理错误将导致代码重复，并可能导致处理不当的错误

代码示例-典型错误流

//DAL layer, we don't handle errors here
DB.addDocument(newCustomer, (error, result) => {
    if (error)
        throw new Error("Great error explanation comes here", other useful parameters)
});

//API route code, we catch both sync and async errors and forward to the middleware
try {
    customerService.addNew(req.body).then(function (result) {
        res.status(200).json(result);
    }).catch((error) => {
        next(error)
    });
}
catch (error) {
    next(error);
}

//Error handling middleware, we delegate the handling to the centrzlied error handler
app.use(function (err, req, res, next) {
    errorHandler.handleError(err).then((isOperationalError) => {
        if (!isOperationalError)
            next(err);
    });
});

博客引用：“有时较低级别的人除了将错误传播给他们的调用者之外，做不到任何有用的事情。”（来自博客Joyent，关键词“Node.JS错误处理”排名第一）

“…您可能会在堆栈的多个级别处理相同的错误。当较低级别无法执行任何有用的操作时，就会发生这种情况，除非将错误传播到其调用方，然后将错误传播给其调用方等等。”。通常，只有顶级调用方知道适当的响应是什么，是重试操作、向用户报告错误还是其他什么。但这并不意味着您应该尝试向单个顶级回调报告所有错误，因为回调本身无法知道错误发生在什么上下文中”

---

数字5：使用Swagger记录API错误

TL；DR：让您的API调用方知道可能会返回哪些错误，这样他们就可以谨慎地处理这些错误而不会崩溃。这通常使用诸如Swagger之类的REST API文档框架来完成

否则：API客户端可能会决定崩溃并重新启动，因为他收到了自己无法理解的错误。注意：API的调用方可能是您（在微服务环境中非常典型）

博客引用：“你必须告诉你的呼叫者可能会发生什么错误”（来自博客Joyent，关键词“Node.JS logging”排名第一）

…我们已经讨论了如何处理错误，但当您编写新函数时，如何将错误传递给调用您函数的代码…如果你不知道会发生什么错误，或者不知道错误的含义，那么你的程序就不可能是正确的，除非是偶然的。因此，如果您正在编写一个新函数，您必须告诉调用者可能发生的错误以及它们的含义

---

数字6：当陌生人进城时，优雅地关闭流程

TL；DR：当出现未知错误（开发人员错误，请参阅最佳实践编号#3）时，应用程序的健康状况存在不确定性。一种常见的做法是，使用Forever和PM2

否则：当捕捉到不熟悉的异常时，某些对象可能处于错误状态（例如，全局使用的事件发射器，由于某些内部故障而不再触发事件），所有未来的请求可能会失败或行为异常

代码示例-决定是否崩溃

//deciding whether to crash when an uncaught exception arrives
//Assuming developers mark known operational errors with error.isOperational=true, read best practice #3
process.on('uncaughtException', function(error) {
 errorManagement.handler.handleError(error);
 if(!errorManagement.handler.isTrustedError(error))
 process.exit(1)
});


//centralized error handler encapsulates error-handling related logic 
function errorHandler(){
 this.handleError = function (error) {
 return logger.logError(err).then(sendMailToAdminIfCritical).then(saveInOpsQueueIfCritical).then(determineIfOperationalError);
 }

 this.isTrustedError = function(error)
 {
 return error.isOperational;
 }

博客引用：“关于错误处理有三种观点”（来自博客jsrecipes）

关于错误处理，主要有三种流派：1。让应用程序崩溃并重新启动它。处理所有可能的错误，永远不要崩溃。3.两者之间的平衡方法

---

数字7：使用成熟的记录器提高错误可见性

TL；DR：一套成熟的测井工具，如Winston、Bunyan或Log4J，将加快错误发现和理解。所以忘掉console.log吧。

否则：在没有查询工具或像样的日志查看器的情况下，浏览console.logs或手动浏览杂乱的文本文件可能会让你忙到很晚

代码示例-Winston logger在运行

//your centralized logger object
var logger = new winston.Logger({
 level: 'info',
 transports: [
 new (winston.transports.Console)(),
 new (winston.transports.File)({ filename: 'somefile.log' })
 ]
 });

//custom code somewhere using the logger
logger.log('info', 'Test Log Message with some parameter %s', 'some parameter', { anything: 'This is metadata' });

博客引用：“让我们确定一些要求（对于日志记录者）：”（来自博客strongblog）

…让我们确定一些要求（对于记录器）：1.每条日志线的时间戳。这一点非常不言自明——您应该能够知道每个日志条目发生的时间。2.记录格式应易于人类和机器理解。3.允许多个可配置的目标流。例如，您可能正在将跟踪日志写入一个文件，但当遇到错误时，请写入同一文件，然后写入错误文件并同时发送电子邮件…

---

数字8：使用APM产品发现错误和停机

TL；DR：监控和性能产品（也称APM）主动评估您的代码库或API，以便它们能够神奇地自动突出错误、崩溃和您丢失的慢部件

否则：您可能会花费大量精力来衡量API性能和停机时间，可能您永远不会意识到在真实场景下哪些是您最慢的代码部分，以及这些部分如何影响用户体验

博客引用：“APM产品细分市场”（摘自Yoni Goldberg博客）

“…APM产品包括三个主要部分：1。网站或API监控–通过HTTP请求不断监控正常运行时间和性能的外部服务。可以在几分钟内设置。以下是几个被选中的竞争者：Pingdom、Uptime Robot和New Relic2.代码检测–需要在应用程序中嵌入代理以帮助实现慢速代码检测、异常统计、性能监控等功能的产品系列。以下是几个选定的竞争者：NewRelic、AppDynamics3.运营智能仪表板–这些产品线专注于通过指标和精心策划的内容帮助运营团队轻松掌握应用程序性能。这通常涉及聚合多个信息源（应用程序日志、数据库日志、服务器日志等）和前期仪表板设计工作。以下是一些选定的竞争者：Datadog、Splunk“

---

以上是一个简短的版本-请参阅此处的更多最佳实践和示例

您可以捕获未捕获的异常，但它的用处有限。看见http://debuggable.com/posts/node-js-dealing-with-uncaught-exceptions:4c933d54-1428-434c-928d-4e1ecbd56cb

monit、forever或upstart可用于在节点进程崩溃时重新启动它。您最希望的是一个优雅的关闭（例如，将所有内存中的数据保存在未捕获的异常处理程序中）。

如果你想在Ubuntu中使用服务（Upstart）：在Ubuntu 11.04中使用节点作为服务，包括Upstart、monit和forever.js

使用try-catch可能比较合适的一个例子是使用forEach循环。它是同步的，但同时不能只在内部范围中使用return语句。相反，可以使用try-and-catch方法在适当的范围内返回Error对象。考虑：

function processArray() {
    try { 
       [1, 2, 3].forEach(function() { throw new Error('exception'); }); 
    } catch (e) { 
       return e; 
    }
}

这是上面@balupton描述的方法的组合。