闲谈错误处理的设计

系统开发中，除了编写正常的业务逻辑外，免不了需要处理各种错误，本文简单讨论了错误处理的思路以及如何正确处理错误。

错误处理的困境

系统开发中，除了编写正常的业务逻辑外，免不了需要处理各种错误，甚至，处理错误的代码可能多于正常业务逻辑代码！

一般的，一个程序员习惯于首先编写正常的业务逻辑，然后，再回头处理各处异常。但是，如果一开始没有一个好的规划，就会发现处理错误的逻辑和正常逻辑搅和在一起，之后的代码往往难于阅读和维护。甚至发现为了处理有些错误，还需要重新修改程序的结构，导致不断地返工和重构。

而如果一开始编写正常业务逻辑的时候，同时考虑各个异常的处理，不仅干扰程序员的思路，需要额外花费大量精力，而且往往难于想清楚系统的业务行为。

也有一些开发语言或框架（譬如 Java），采用“抛出异常、统一处理”的方法，将这种窘境推迟到正常的业务逻辑编写完成后。但是，这种粗暴的处理错误的方法很难给用户带来更好的体验。举例来说，只要有异常发生，就跳转到错误页面，那么用户可能会过多地被指向错误页面，产生厌烦的心情；而事实上，有些异常对于用户是可以忽略的，或者采用一些折中的办法代替。这样做，可以给用户带来更好的体验。

现代软件开发中，流行小巧（譬如微服务）、敏捷的开发方法。往往是产品经理规划了大致的业务逻辑，程序员就开始干活儿了。那么，在编写代码中，各种细节的处理就都得由程序员来完成。

其次，现代的软件系统几乎不可能不和外界交互，往往需要调用第三方 API。即使第三方 API 非常强壮，也要假设它是不稳定的，因为网络本身是不稳定的，所以就要处理调用失败的情况，以及各种返回值的可能性。

最后，现代的软件系统的运行平台往往是多样的。譬如，手机 App 会由于手机不同而有一些不同的行为；Web App 会由于浏览器不同而不同；即便是服务端的系统，考虑到云环境、自动部署、失败迁移和恢复、微服务调用、消息队列、缓存等技术，也有比以往更为复杂的错误处理需要考虑。

错误处理的思路

我们都知道，在动手开发一个软件系统之前，如果能很好地规划软件系统中的错误处理，不仅可以使代码逻辑清晰、易于修改和维护；而且可以避免在编写正常业务逻辑的同时考虑错误情况，使程序员专注于编写正常的业务逻辑；最棒的是，可以更精细地控制错误，带来更好的用户体验。

那么，如何规划一个软件系统的错误处理？

为了想清楚这个问题，我在下面给出规划软件系统错误处理的思路。

编写错误处理的目的有两个，一是确保系统可以向外界（最终用户或其他系统）尽可能提供服务；这里所谓的“尽可能提供服务”包括，

• 当发生非致命错误时，系统服务不会中断（譬如系统挂掉了）；
• 当发生错误导致某些功能不可用时，可用的功能仍然可以提供服务；
• 当发生错误导致某些功能不可用时，不可用的