如何设计系统的错误码及错误信息

一个软件系统，肯定是涉及到很多错误信息。比如用户执行出错了，软件需要将错误信息返回给用户。那么如何设计错误码及错误信息呢？错误信息如何返回？下面以一个简单的场景来说明。比如现在我们一个UI模块（界面模块）和一个Algo模块（算法模块），其调用关系如下图：

        在这里要提及一个很不好的编程习惯，就是在假如在Algo模块内部出错，开发人员往往在Algo模块里弹出错误信息提示框。这种习惯是很不好的，不好在哪里？在于一个算法模块应该尽量减少界面元素的侵入，如果一个算法模块带有界面元素，往往限制了这个界面模块的移植性，比如从一个界面框架移植到另一个界面框架，从一种操作系统移植到另一种操作系统。正确的做法是怎么样的呢？就是算法模块应该返回错误码给界面模块，界面模块通过错误码获取错误信息来弹出错误信息。

        如何设计错误码？在这里我们先考察一下他人的做法，比如Windows API。在WindowsAPI中有不少函数是BOOL类型的，函数的返回值一般就是返回TRUE表示成功了，返回FALSE表示失败了。如果用户需要更详细的错误信息，需要调用一个GetLastError的函数来获取错误码，再根据错误码来获取错误信息。

        Windows API这种设计好不好呢？在我看来它勉强可以解决问题，但是存在一些弊端。弊端一在于需要使用全局变量把错误码保存下来。大家知道，全局变量是使用越少越好的。弊端二在并发时可能出错。比如在多个线程中同时调用同一个函数，错误码如何区分这几次调用呢？有解决这个问题的办法，但这个解决办法又增大了系统的复杂性。

        有没有更好的设计？更好的设计就是函数的返回值不再返回BOOL型，而是返回int类型。返回的int值表示错误码，界面模块根据错误码来获取错误信息。这样的话错误码就仅仅需要是一个临时变量了。

        当然问题还是有的。比如有多个算法模块，如何避免它们占用同一个错误码，比如100？我设想的是有一个全局的动态增加错误码起始值的函数，以100位区间。比如A算法模块的错误码区间为100到200，B算法模块的错误码区间为201到300。

        说完错误码的设计，我们再谈谈错误信息的设计。错误信息的设计也是有学问的。首先我们需要明确一点，错误信息应该面向什么人？可能有人笑了，这还用问，错误信息不就是面向软件用户的吗？这个答案对，但是不完整。首先错误信息确实是面向软件用户。明白这点我们就该想到好的错误信息不应告诉用户现状是什么，更应提示用户怎么解决问题。诸如“数据处理失败”就不是好的错误信息，因为这仅仅是告诉了用户现状是什么，如改为“数据处理失败，原因是xxx输入参数输入不正确”更好，因为它揭示了解决办法，用户看到了明白了是因为输入了错误的xxx参数而导致处理失败的。下次他操作时就会注意输入这个参数了。错误信息除了面向用户，还应面向谁？还应面向开发者。因为出错后用户只能把自己的操作情况及看到的错误信息告诉技术支持人员，而技术支持人员最终把错误信息反馈给开发者。因此错误信息详细一点不是坏事，用户看不懂问题不大，开发者却可以凭借这个信息来帮助用户解决问题。