最近在极客时间上学习左耳朵耗子大佬的左耳听风栏目，收益颇多，决定对从课程中学习到的东西进行总结记录以加深印象。

今天学习的课程主要是对代码中错误处理的方式从各个语言的实现角度做了介绍并提出了一些自己对于错误处理的最佳实践，这里对????大佬提出的一些最佳实践进行自己的理解和总结（说到错误处理就想到自从我入职之后从Java转到Golang开发，确实明显感觉到了两种语言对于异常错误处理的不一致，还经常还无法习惯golang中的error处理形式）

1.统一分类的错误字典

这个在进行http接口开发的时候体会的比较深刻，因为http中的返回错误码的形式就将错误进行了分类，2XX开头的表示正常的请求，3XX表示重定向，4XX表示客户端请求有问题，5XX表示服务端的问题。所以我后来做一些第三方调用接口的开发时偶尔会将错误进行分类用错误码+msg的形式返回错误到调用方

2.同类错误的定义最好可以扩展

类似于Java中的Exception和Golang中的error可以用多态的方式做到代码复用

3.定义错误的严重程度

感觉这个一般用在日志记录的时候，根据问题严重性打印error，info，warning等级别的信息

4.错误日志输出最好用错误码而不是错误信息

确实在做开发时某些地方打印错误日志直接就把error或者Exception信息打印出来，导致在排查问题时没有关键词进行搜索很难找到出错的那行日志在哪。所以打印错误信息的时候有必要增加一个标识符表示这个错误日志发生的地点，我现在一般都是用唯一性的一句description，这样看来用错误码好像是更高级点的方式

5.忽略错误要有日志

方便问题排查，不用多说

6.对于同一个地方不停报错，最好不要都打到日志里

to do

7.不要用错误处理逻辑处理业务逻辑

就是要记住一个原则异常捕捉是用来处理不期望发生的事，比如空指针异常等，错误码就可以用来处理可能会发生的事，比如第三方接口调用时可能出现的参数错误，鉴权信息有误等

8.对同类错误的处理用同一种模式

主要是代码规范

9.尽可能在错误发生的地方处理错误

todo

10.向上尽可能返回原始的错误

这个就踩过坑，在某次开发时我捕获了一个方法的异常然后在异常处理中没有将这个异常打印出来，然后还返回了一个很模糊的报错信息给上层，导致最后排障的时候特别坑。。

11.处理错误时要清理以分配的资源

12.不推荐在循环体内处理错误

一般把循环体整个放在一个try-catch内

13.不要把大量代码都放在一个try语句块内

14.为错误定义提供清楚的文档以及每种错误的代码示例

todo

15.对于异步的方式推荐用promise模式处理错误

在真实的开发中我还没用过promise模式，觉得看着挺刁的以后找机会实践一下

有疑问加站长微信联系（非本文作者）