Nodejs：为什么要在closures过程中发生错误？
Nodejs的默认行为是在主事件循环发生错误时closures。 该手册强烈build议不要重写此行为（例如，通过process.on('uncaughtException ）。
给出的解释是：
一个未处理的exception意味着你的应用程序 – 通过扩展node.js本身 – 处于一个未定义的状态。 盲目恢复意味着任何事情都可能发生。
当你升级你的系统的时候，考虑重新拔电源线。 十次中有九次没有任何反应 – 但是第十次，你的系统是破产的。
有人能详细说明吗？ Chrome使用与节点相同的V8引擎，默认情况下在未捕获的错误之后恢复其事件循环，并且AFAIK不会导致任何问题。 所以似乎没有任何内在原因，V8无法从未捕获的exception中优雅地恢复。 在节点内部有什么行为不同于Chrome吗？
答案与引擎自身重启的能力无关。
它与你自己的应用程序代码有关。 如果发生未处理的exception，那么理解你的应用程序的状态本质上是没有办法的。 如果有，那么它不会是一个未经处理的例外。 而且，如果你不了解你的状态，那么你就不能确定更多的未处理的exception不会继续发生，随着时间的推移，最有可能导致越来越差的问题（因为意外的状态级联到越来越多的意外状态）。
把它想象成在服务器上运行的代码（因为它并不是特定于node.js）：
start process open two server sockets process incoming requests
如果你没有处理exception而打开第二个服务器套接字失败，那么你的应用程序就不能工作。 在下一个逻辑步骤重新启动线程也可能无法正常工作。 重新启动引擎不能合理地closures一个套接字，并且不可能修复第二个故障的原因（很可能该端口已经在使用中），并且如果它closures了成功打开的套接字，则它具有更好的重新启动应用程序，以便它可以重新打开（否则它变得更糟糕）。
这可能是一个明显的例子，但现在想象你是一个graphics应用程序（例如，一个游戏）：
start process load models handle state (until closing) draw screen
如果任何模型在没有exception处理的情况下加载失败，则该过程不能合理地继续，因为它在绘制时会造成更多的错误。
有些情况下，从未处理的exception中恢复是合理的。 在大多数客户端GUI框架中，有一种方法来注册未处理的exception，这允许重新启动事件线程（GUI线程），类似于Chrome的V8恢复。 这是危险的，因为恢复是不能保证的; 无论什么原因导致未处理的exception仍然可以在内存中，并准备在下一次使用它时再次导致exception。 但是，也可能有一个很好的应用程序可以足够小，以消除自己的干净考虑到这种例外。 这种处理程序（处理未处理的exception）的最佳用法是loggingexception，以便修复问题。
换句话说：设想一个exception发生，你没有在你的应用程序在任何地方处理。 你能做些什么来解决这个问题，以防止在代码的下一个阶段发生？ 为了安全地回答，这意味着你知道是什么造成了这一点，这意味着：A）它不应该被处理，B）它是孤立的。
唯一保证的安全重置是从一开始就启动，这意味着重新启动应用程序。