Skip to content

Latest commit

 

History

History
51 lines (33 loc) · 3.27 KB

operationalvsprogrammererror.chinese.md

File metadata and controls

51 lines (33 loc) · 3.27 KB
Raw

区分操作型错误和程序型错误

一段解释

区分以下两种错误类型将最大限度地减少应用程序停机时间并帮助避免出现荒唐的错误: 操作型错误指的是您了解发生了什么情况及其影响的情形 – 例如, 由于连接问题而导致对某些 HTTP 服务的查询失败问题。另一方面, 程序型错误指的是您不知道原因, 有时是错误不知道来自何处的情况 – 可能是一些代码试图读取未定义的值或 DB 连接池内存泄漏。操作型错误相对容易处理 – 通常记录错误就足够了。当程序型错误出现，事情变得难以应付, 应用程序可能处于不一致状态, 你可以做的，没有什么比优雅的重新启动更好了。

代码示例 – 将错误标记为可操作 (受信任)

//将错误标记为可操作 
var myError = new Error("How can I add new product when no value provided?");
myError.isOperational = true;
 
//或者, 如果您使用的是一些集中式错误工厂 (请参见项目符号中的示例"仅使用内置错误对象")
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);

博客引用: "程序型错误是程序中的 bug"

摘自博客 Joyent, 对于关键字“Node.JS error handling”排名第一

…从程序型错误中恢复的最好方法是立即崩溃。您应该使用restarter运行程序, 以便在发生崩溃时自动重新启动程序。在一个使用了restarter的地方, 在面对一个瞬态程序型错误, 崩溃是最快的方式来恢复可靠的服务…

博客引用: "不伴随着创建一些未定义的脆性状态，没有安全的方式可以离开"

摘自Node.JS官方文档

…在 JavaScript 中, throw的工作性质, 几乎没有任何方法可以安全地"在你离开的地方重新捡起"，没有泄漏引用, 或者创建一些其他形式的未定义的脆性状态，。对引发的错误进行响应的最安全方法是关闭进程。当然, 在普通的 web 服务器中, 您可能会打开许多连接, 并且由于其他人触发了错误而突然关闭这些连接是不合理的。更好的方法是向触发错误的请求发送错误响应, 同时让其他人在正常时间内完成, 并停止侦听该工作人员中的新请求。

博客引用: "否则，您置您应用的状态于风险之中"

摘自博客 debugable.com, 对于关键字“Node.JS uncaught exception”排名第3

…所以, 除非你真的知道你在做什么, 否则你应该在收到一个"uncaughtException"异常事件之后, 对你的服务进行一次优雅的重新启动。否则, 您应用的状态, 或和第三方库的状态变得不一致, 都被置于风险之中，导致各种荒唐的错误…

博客引用: "对于错误处理，有三种学院派想法"

摘自博客: JS Recipes

…对于错误处理，主要有三种学院派想法:

  1. 让应用崩溃并重启.
  2. 处理所有可能的错误，从不崩溃.
  3. 两者之间的折中方案