给出的解释是：
An unhandled exception means your application – and by extension
node.js itself – is in an undefined state. Blindly resuming means
anything could happen.Think of resuming as pulling the power cord when you are upgrading
your system. Nine out of ten times nothing happens – but the 10th
time, your system is bust.
有人可以详细说明吗？ Chrome使用与节点相同的V8引擎,默认情况下在未被捕获的错误后恢复其事件循环,而AFAIK这不会导致任何问题.因此,似乎没有任何内在原因导致V8无法从未捕获的异常中优雅地恢复.节点内部是否存在与Chrome不同的行为？
答案与引擎重启自身的能力无关.它与您自己的应用程序代码有关.如果发生未处理的异常,则无法理解应用程序的状态.如果有,那就不会是一个未处理的例外.而且,如果您不了解自己的状态,那么您无法确定更多未处理的异常将不会继续发生,最有可能随着时间的推移导致更糟糕的问题(因为意外状态会逐渐陷入越来越多的意外状态) ).
想象一下这是在服务器上运行的代码(因为它根本不是node.js特有的)：
start process open two server sockets process incoming requests
如果您未能在不处理异常的情况下打开第二个服务器套接字,那么您的应用程序可能无法正常工作.在下一个逻辑步骤重新启动线程可能也无法正常工作.重新启动引擎无法合理地关闭一个套接字,并且不太可能修复第二个故障的原因(很可能端口已经在使用中),如果它确实关闭了成功打开的套接字,那么它最好重新启动应用程序,以便它可以重新打开(或者它使它变得更糟).
这可能是一个明显的例子,但现在想象你是一个图形应用程序(例如游戏)：
start process load models handle state (until closing) draw screen
如果任何模型在没有异常处理的情况下加载失败,则该过程无法合理地继续,因为它只会在绘制时导致更多错误.
在某些情况下,从未处理的异常中恢复是合理的.在大多数客户端GUI框架中,有一种方法可以注册未处理的异常,这允许重新启动事件线程(GUI线程),类似于Chrome的V8恢复.这很危险,因为无法保证恢复;无论如何导致未处理的异常仍然可以在内存中并准备好在下次使用时再次导致异常.但是,如果有这样的例外情况,那么开发良好的应用程序也可能足够小,可以擦干净自身.这种处理程序的最佳使用(处理未处理的异常)是记录异常,以便解决问题.
换句话说：假设您在应用程序中未处理任何异常.您可以做些什么来修复它,以便在下一次代码传递时不会发生？为了安全地回答这意味着你知道是什么导致它,这意味着A)它不应该是未处理的,B)它是孤立的.
唯一保证的安全重置是从一开始就开始,这意味着重启应用程序.