Callback Promise Generator Async-Await 和异常处理的演进 about blog HOT 8 OPEN

@paranoidjk 滥 try 确实非常影响代码质量，在前端建议只在调用第三方接口时使用（比如发 http 请求），这已经是业务层行为，还是比较合理的。

至于框架层，兜住异常并吞掉是自取毁灭的行为。

from blog.

如果每个类中的方法都用try/catch包裹，是否有性能问题？

from blog.

@acthtml 异常可以在最外层统一处理，可以不用每个可能出现异常的地方都写上try/catch

from blog.

@codezyc 我的意思就是使用Decorator之后，对性能影响如何？ 不过这个异常捕获方案的确不错。

from blog.

@acthtml

装饰器仅在初始化时工作，此时函数已被替换，性能问题基本上可以忽略。

try catch 造成的性能影响不必担心，try 中直接调用函数，性能几乎不受影响，而带来的可维护性价值很大，见下图：

几乎所有程序都需要错误上报机制，就算自己不写 try catch，库不写 try catch（库中含有大量的 try catch），业务代码最上层也会有 try catch 捕获和收集异常，所以不用纠结，现在就开始用吧~

from blog.

写的太赞了，我也要把这个方案应用到我的项目中

from blog.

用 decorator 来做切面异常处理的思路很赞。

对写 try catch 这一点做下探讨

业务方也不需要判断程序中是否存在异常，而战战兢兢的到处 try catch，因为程序中任何异常都会立刻终止函数的后续执行，不会再引发更恶劣的结果。

在浏览器端可能是这样，但在后端思路可能是 fail fast，不要兜住任何开发者编程时预知不到的错误类型，开发者不应该到处 try catch，由多进程模型来保证高可用，比如 egg 的 cluster。
更严格的语言甚至会要求对 Error 类型做静态的分析和检查，比如 http://www.yinwang.org/blog-cn/2017/05/23/kotlin

from blog.

异常真正的应用场景是异常场景

from blog.