Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

对uncaughtException的一些感慨

  早期的NodeJS就提供了uncaughtException事件来全局捕获程序中未捕获的异常,但目前官方强烈反对使用uncaughtException事件。虽然后来的domains也可以完成同样的工作,但不管这个事件的实现如何,我觉得它的概念是服务器必须的。
  其实domains模块和uncaughtException事件是完全不同的概念了,domains相当于一个JavaScript自带的try语句的扩展。JavaScript自带的try语句只能捕获当前消息中的事件;而domains可以捕获一个调用链的事件,它可以跨消息捕获。但它们的功能是一样的,捕获一个预期可能发生的错误。比如开发者已经预测到一段代码中可能会出现未接住的异常,所以使用这些方式来捕获。它们是针对局部的!
  实际上我的程序中对try语句的使用并不多。因为很多异常既然是可预测的,直接从根源上解决掉了。只有一些特殊的功能需求才会使用try。对于可预期的错误而言,异常捕获并不是必须的。当然如果使用这些异常处理,在一些场景下可以带来很大便利。domains模块的提供确实是非常好用的工具,但我不认为它是uncaughtException的替代品。
  uncaughtException事件是全局的,它捕获的是不可预期的异常。比如一些引用的外部库带来的异常,或者由程序设计上的一些缺陷带来的异常。对于这类异常,除此之外还有什么更好的处理方式吗?官方文档中不建议使用它是因为它被滥用了,很多人用它来完全屏蔽错误,这样掩耳盗铃的做法当然是不可取的。这类异常需要记录下来,把它们逐个解决掉,尽可能地使用可预期的方式把异常处理掉。注意我们只能尽可能地避免,无法完全杜绝。这类异常完全不出现是不可能的,即使一个最简单的“Hello World”程序也可能因为一些系统环境的原因而抛出异常。所以无论何时我们总是需要一个全局的异常捕获来处理这类异常。
  实际上使用uncaughtException事件和把domains挂到全局上没什么区别。如果以后的版本移除了这个事件,那么domains挂到全局上的做法可能又会带来同样的问题。错误日志和崩溃重启机制是服务器必要的东西,而这些东西的本质就是未捕获的异常处理。
  我觉得uncaughtException好无辜!实现粗糙?优化好不就得了,至于把它杀掉吗?
网名:
3.80.32.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^