如何评价 JS 的错误处理？

[dou4cc]

throw...try...catch...finally 和大多数 domexception 是默认冒泡的， abstractworker.onerror 不冒，然后 promise.reject 可以延迟处理，却又出了个 onunhandledrejection

。。。

这是否意味着js从及时报错哲学转向带错执行哲学？
其实我一直不懂错误处理的初衷，上下文丢失是很讨厌的事情，但错误处理不能规避死循环，其还原上下文的能力非常有限

[xialdj]

有啥好评价的啊 应用内要用 try catch 的地方都用 if 来处理就可以了 只在应用的最外层做一个 try catch 来作为保护

[MinonHeart]

JS ：你的哲学我不懂

[otakustay]

首先你要能把语言和应用环境分开，这个问题才有讨论的价值， js 的错误处理很简单，就一个 try/catch/finally ，没有冒泡没有全局处理

而你说的 domexception 、 onerror 、 unhandledrejection 都是应用环境下的异常处理，这在任何一个语言 /框架里都是存在的，比如 ASP.NET 的 Application_Error ，比如 Spring MVC 的 @ControllerAdvice ，比如 ROR 的 exceptions_app ，在一个应用环境中，异常一定是要“冒泡”到全局下统一处理的，否则造成应用的崩溃在生产环境是一件非常危险的事情

[dou4cc]

@otakustay try/catch/finally 也算冒泡，如果不考虑 tick ，可以处理全局错误

[otakustay]

@dou4cc 你要这么算也行，我没见过 exception 不冒泡的语言

[dou4cc]

@otakustay go

[murmur]

js 设计的不合理之处不是一点两点了， exception 和 promise 的问题，习惯就好了
有句话说，错就错到底，就算错了大家都学会了就成了 feature
结果看箭头函数的 this ， array 新函数对空白位的处理，这异常又多个黑点

当然我习惯是 if 把条件全检查好了，如果这都能出异常那真是牛逼。。

[chemzqm]

同步: .try...catch
异步: promise.reject
全局错误: onunhandledrejection
只是某些例如 jquery 这种库为了操作 dom 方便把 dom 操作的报错去掉了，所以某些人会觉得混乱
上下文丢失是实现问题，并不是设计问题，要么使用辅助库，要么等修复完善

[billlee]

@dou4cc Go 那个不叫 exception 吧，你怎么不说 C 呢

[zlgodpig]

年轻的时候也经常思考各种设计是不是正确。现在觉得，对于 `javascript` 这样的东西，思考太多并没有什么用，爱用用不用滚是一般的结论，（摊手