异常处理的规范

[otakustay]

我想就异常处理方面做一些规范和实践指导性质的工作，主要会包含：

1. 在哪些场景下需要进行异常处理
2. 常见异常的message的格式
3. 异常应该带有的额外属性，如NodeJS的异常多数带有一个code属性
4. 异常模式下如何处理异常

这么做希望的收益是：

1. 由工程师被动执行来提升代码的质量
2. 可以用一个库来支持异常的处理，进行面向约定的编程，如使用assert.hasArgument('name', name)而不是if + throw
3. 一样的异常有一样的message格式，利于对异常日志的分析
4. 通过类似code属性来分类异常，同样有助于异常的分析
5. 能够为业务系统建设统一的异常日志记录、处理、统计、分析的平台，将工作平台化，减少每个系统自己玩一套的精力浪费

各位不知有什么看法？

[erik168]

1. 这个需要分browser和node吧，模式不同异常处理的思路也不同耶
2. 想做啥？一个规定和指导性质的spec，一个assert库，还是更biz的东西？

[Justineo]

支持~

@erik168 要落地的话这几样东西都要有的吧

[otakustay]

@erik168 你换ID真勤……

1. 我认为1-3点不用区分，什么场景处理异常，如何处理，这是编程通识，JAVA也会这样C++也会这样，更不用说同一个语言的平台。第4点会很好地去覆盖Node style、Promise、Double callback等形式吧
2. 产出一个spec、一个assert库，后续一套日志收集分析统计展现的平台（也可单独部署），以及相关的培训

[errorrik]

那等你spec的初稿。再换一次id

[chriswong]

线上的异常怎么追踪到源码，sourcemap 吗？

貌似 T 和 A 有在做，不知道什么情况

[otakustay]

我觉得sourcemap反向是可行的，这个必然需要工具

但从另一个角度来说，如果各种异常处理得好，抛出时的message能精确描述出现的问题，你觉得需要用工具来定位源码？一看message立马就知道在哪里了吧？

[Justineo]

一般来说线上出 bug 往往是由于 uncaught exception 吧？就是因为写代码时没考虑好才要源代码位置来帮助 debug 吧。

[otakustay]

uncaught exception有2种，第一种是我们的现状，即整个儿没有异常处理，片片出错是xxx is undefined、xxx is not a function，这种错误没有源码位置基本上是不可能排查的了

第二种是我们希望达到的目标，即系统本身有一些异常的控制，因此出现的异常属于“不预期会出现但作了防御措施”的，比如这样的代码：

exports.get = function (key) {
    if (!key) {
        throw new Error('You must provide a "key" argument when get property from model');
    }

    return this.store[key];
};

我们在编程的时候，防御了“key为空”这一事情，因此当出现异常时，会有非常明确的message，一看就知道是访问model时没有提供key，再根据当前页面的URL判断是哪一个Model，辅以上层捕捉到异常时追加的信息，立即就能定位到较为精确的范围，这种情况下完全可以不在乎线上代码是压缩的

我明白“不要防御性编码”这一原则，但这一原则从来不代表我们不要对异常状态进行控制

[errorrik]

个人认为：

1. sourcemap还是有必要做的。
2. 在哪些场景下需要进行异常处理的设计，应该在有sourcemap的前提下考虑

[otakustay]

我理解sourcemap是个锦上添花的东西？不太理解啥事情是必须有sourcemap为前提设计的，以没有为前提的设计应该在有sourcemap的情况下都能工作吧？

在 2014年10月13日，下午8:06，errorrik [email protected] 写道：

个人认为：

sourcemap还是有必要做的。
在哪些场景下需要进行异常处理的设计，应该在有sourcemap的前提下考虑
—
Reply to this email directly or view it on GitHub.

[errorrik]

因为，如果能直接通过默认错误和�定位代码行追查到错误，这样的场景就不需要进行防御式编程。

“这样的场景”大部分指的是基础lib或framework，对接受参数是否存在或类型之类

[otakustay]

认可这个说法，不过还是想说明一点，防御性编程和正确的异常处理并不是一回事，很多人会误把应该做的正确的异常处理认为是防御性编程（或者纯粹只是种借口），老实说除了JS我没见过哪个语言生态圈能把异常处理做得这么烂到没边的，各种第三方库都完全不管输入异常的情况，这很大程度上直接导致了JS维护难度的提高

另外，SourceMap这东西，方向没问题但最好不要有太大的期望，要做SourceMap为基础的StackTrace反向跟踪有很多的事：

1. 是基础的，建立反向跟踪的算法
2. 因为有文件合并的存在，精确定位开发期源码需要建立跨文件的SourceMap追踪
3. 建立历史源码库，不能v1.0的StackTrace用最新版v1.1的SourceMap去反向跟踪

上面这3点无论哪点不是难就是烦，我不看好365天内我们可以有什么实质性的系统建设出来