异常设计，这个概念还真是第一次听说，挺新鲜的。文中学习到了，如果能这样对待异常，系统化的管理异常，治理异常，我相信产品的质量和用户体验一定非常棒！

这节课的内容让我联想到了我们团队的迭代回顾会议（Restrospective），我们在这个会议上都会一起回忆这个迭代做的好 和 做的不好 的场景和事件，对于做的好的就继续保持，对于做的不好的（往往是多个点）就投票从中选择一个点，然后通过5 Why等方法对其进行分析根本原因，然后针对根本原因探讨一个解决方案，然后将解决方案作为一个规则 或 嵌入研发流程 或 嵌入CI/CD流程等，确保指定负责人或所有人必须按流程执行，以保证后续迭代不再犯同样的错误，让团队持续改进。现在看来，这些做的不好的，影响团队协作效率的点，其实就算是团队层面的一个异常，它导致了我们团队可能有潜在无法满足用户契约的可能性，于是我们通过回顾会议对其进行了异常的统计、分析 和 处理（按优先级，正如不是所有异常都要被处理），对于团队一致认为需要在后续迭代处理的，就严格定义规则嵌入研发流程保证执行。团队的异常不断减少（但始终无法完全消灭完），能够持续的进化，就是对用户契约精神的遵循，对企业长期主义的践行。

乔老师说的太对了，契约精神是做好工作的原动力，所有工作都要以终为始，通过闭环体系化管理，有道也有术，受教了！

乔老师好，认知又得到了提升 "异常，是导致不能履行契约的所有问题" 请教一个工程层面的问题，写代码时，如果当前已经捕获异常，有两种处理方式 1.在下层处理一下，包装成返回码； 2.直接抛出异常，由出口统一处理 您偏向那种方式?

乔总再三强调“契约精神”，我的理解就是做一个靠谱的工程师。

风险管理和应急处理、事后复盘；说起来容易，可是真正做到确实不易。

学完这节课内容我的思考是，这节课讲到的异常设计和前面几讲里的内容就像系统里的基础组件，可以类比为房子的地基，地基打的越牢固上面的房子越稳固。可正是因为他们是地基在底层，平时不显山不露水只有当发生问题引发灾难时才被人想起，所以很多人对他们没有意识，或者将他们一直放在重要不紧急的任务列表里，一直处于等待状态，这样企业就缺少了契约精神和持续进化能力。 有了这样的意识后要把他们坚持落地困难还是挺大的，昨天在部门会议上提到团队目前监控设计还有很多事情要做，生产环境出现问题后直接在生产环境调试解决 Bug，即便回滚也不能完全回滚到未变化前版本，团队 Leader 对此并不在意，并指出"规定不能在生产环境调试 Bug" 太叫针儿。改变不了别人，只能改变自己，努力学习提升认知，即使现在不能实践至少知道什么是对的。

异常体系化的管理，确实还是第一次听说，很有启发意义！这里的异常，更多还是业务层面的异常，具有业务含义的。体系化解决异常，让我想到了项目管理的办法。异常要拆解到位(异常注册)，责任到人，长期持续推进，这其实就是项目管理的思路。

老师，你好！像我们中小公司，之前自己开发过一个系统，推广不太顺利。后面想，是不是利用sentry来管理日志？异常，更多的认识是日志的级别和处理。总而言之，我们不能自己去开发一个系统，也一下子找不到开源系统。