跟我学C++中级篇——错误的处理机制

一、问题控制

无论是在现实世界还是在计算机制世界中，出问题是一种常态，不出问题是一种非常态。那么就产生了一个如何处理问题的哲学。当然如果能够消除掉问题的提出者，那么更好。但实际情况往往问题的提出者是金主甲方，所以只能解决问题了。
解决问题有两套思路，一种是由发起者处理各种提供服务者出现的问题，这是一种常见的思路，毕竟谁办事儿谁负责；另外一种就是发起者只管结果不管过程中如何对问题的处理，只是简单的报给相关的提供服务者即可。前者是发起者大包大揽，后者是铁路警察各管一段。
哪种更优呢？没有更优，只有更合适。
具体的计算机中，一种就是由调用者处理的异常控制；另外一种就是常见的返回错误码。异常控制在C++中可能不是多么普及，但在其它一些高级语言中非常多，级联的堆栈异常可以很清晰的表明问题出现在哪儿。而错误码在调用系统应用是非常多，比如内核某个函数调用返回一个-3,-3表示是地址错误。下面就这两种情况进行一下简单的分析说明。

二、错误码

错误码非常好理解，就是错误的ID。这就和交通指示灯的红灯停绿灯行是一个道理。错误的优点在于清晰明白，非常容易被开发者接受，即使有不太清楚的查看一下相关的说明也能够理解是怎么回事。
但是，错误码有一个问题，它只能定义可知的或者说可预知的。而对一些动态的、随机产生的异常或错误，它是无法正确返回的。或者说，当有一种错误码有N种情形可以产生时，就不好确定是哪种错误了。错误码一般不会有性能上的考虑，毕竟只是返回值的处理。
使用错误码一定要有一个良好的习惯，对所有的错误码有一个非常好的注释或者有专门的说明文档，并且需要定时维护和更新。只有这样错误码才会起到应有的作用。

三、异常控制

异常控制，就是类似于操作系统的陷阱，错误可以通过异常一层层的如洋葱一样的抛到调用者的层面。调用者看到异常的说明，基本就明白是什么错误了。当然，异常的抛出也不一定全是准确的，有的可能也是模糊的。但相对于错误码，特别是针对动态运行时产生的问题，异常要准确很多。
异常需要处理堆栈信息，所以对于一些随机的不可预见的以及动态生成的问题非常容易体现出问题出现在哪处，从而更容易定位解决问题。但优点往往就是缺点，处理堆栈，就意味着空间和性能的损失。
另外一个重要的确定方式就是在与第三方或系统进行编程时，要保持一致性。比如大量的底层API调用，返回当然是错误码而尽量不要选择异常处理。第三方如果给上层调用抛出一个异常，你搞错误码不就是没事找事做么？
异常的处理有一个建议，尽量使用标准的异常，也就是继承或直接使用STL标准库中的异常类。

四、实际的应用

知晓了错误码与异常的控制后，如何进行选择呢？其实非常容易。那就是根据实际情况，能直接控制的，尽量选择错误码（包括在C++中使用枚举）。而对于一些影响到程序运行的稳定性和安全性的能随时可能产生的一般建议选择使用异常控制。
在实际的开发过程中，为什么经常禁止使用异常。这里面有一个重要的原因，除了性能的问题外，一般来说，在C/C++中的严重的异常问题（包括动态生产的等），比如内存问题、指针问题等往往程序就直接Crash了。这时，再好的异常抛出来也没有什么用了。
所以，异常的处理往往就这样尴尬了。但这并不代表异常没有用武之地，在一些明确有异常抛出的相关库的API中异常还是很有用处的。或者开发者自己封装相关的错误当做异常抛出，在某些情况下也会起到很好的控制作用。
从目前实际看到的开源代码来看，异常更倾向在业务逻辑的上层应用，中下层一般以返回错误码居多。所以这也可以是开发者如何使用二者的一个大方向上的推荐，在底层，特别是接近于硬件的底层，建议使用错误码；在上层业务或UI上可以考虑使用异常，但个人建议要严格限制异常的使用。
掌握这些大原则后，在实际应用中再根据实际情况，适当的进行个别的处理即可。还是那句话，合适的就是最好的。

五、总结

这篇文章是有感而发。里面大多是一些实际的应用而不是技术的分析，大家可以见仁见智，批评讨论！