【编程好习惯】判断函数的返回值

调用一个函数后要检查函数的返回值，以决定程序是继续应用逻辑处理仍是出错处理，这理应是一个常识，但在现实中，却存在大量不检查函数返回值的代码。既然是常识，但却得不到重视，这不能简单地说程序员不知道其危害性。相信读者也明白不检查函数的返回值其危害是什么，所以，也不打算举例说明其所带来的问题，而是试图去探究程序员为何不按这一常识去作。

要判断函数的返回值，不可避免地要面对一个问题 —— 出错了怎么办？这显然不是一个简单的问题，在这问题的背后多是在问：在项目中一个错误如何表达？项目是否认义了出错处理的准则或机制？

若是一个项目没有一种有效的方法表达一个错误，那么就会出现对于出错处理的混乱情况。当出现错误时，仅仅经过C库中已经定义了的那么几个错误码并不能有效地表达应用错误。之因此须要有效地表达各种错误，是由于针对不一样的错误可能须要采用彻底不一样的出错处理方法。不一样的错误可能收敛于几个错误类别，但仍是存在必定程序的发散性。没有有效的方法去定义一个错误，势必会形成程序员在面对函数返回错误时须要进行大量的思考，其所带来的我的思考成本仍是很高的，进而程序员干脆就不去考虑它。在《错误管理》一文中介绍了一种经过定义错误码表达错误的方法，项目中这种相似方法的存在，能大大地下降程序员个体在面对函数返回错误时的思考成本。从程序员的角度来讲，若是项目没有一种明确的错误表达方式，且即便按其我的的想法进行错误处理也最终会进入一种混乱状态，也就是说考虑与否可能结局都是同样的，只是从一种混乱形式变成了另外一种，这应当是程序干脆不进行出错处理的一个重要缘由。

一个项目光定义好了一种通用的方法去表达一个错误就行了吗？为了进一步说明问题，须要借助必定的项目实际来帮助继续分析。假设一个电信产品是进行电话呼叫处理的，在这个产品中的呼叫处理模块对于每个用户电话链接的创建，都须要从DSP处理器上获取一个DSP通道（读者能够想到会有一个DSP通道管理模块存在于系统中）以对电话语音数据进行编解码工做，那么当DSP通道被用尽了之后呼叫处理模块该怎么办？显然，这里DSP通道用尽就是一种错误，若是这个错误被定义成了一个错误码ERROR_CP_NOCHANNEL，那进一步的问题是，这一错误出现时，呼叫出理模块应当采起怎样的处理呢？可能的作法有：
1) 因为系统有必定的用户容量限制，DSP通道的用尽意味着用户数量超过了系统所能处理的最大用户数，所以，这种情形下即便出现了ERROR_CP_NOCHANNEL错误，也只需记录一个错误日志，并结束对这一用户的后续呼叫处理逻辑。或许，ERROR_CP_NOCHANNEL的出现严格地说不是错误。
2) 虽然系统有最大用户数的限制，但经过程序中的统计变量能够肯定，当前的用户数根本没有超过最大用户数。所以，ERROR_CP_NOCHANNEL错误的出现意味着系统有严重的资源泄漏，从而形成DSP通道不足，此次是真正的错误了。若是是这样又有两种出错处理方法。其一是直接对产品进行复位，如此一来，就解决了资源的泄漏问题，但其缺点也是明显的，即在复位时，原本正在通话的用户将会出现掉话的问题。其二，只是记录一个错误日志，而后终止对这一用户的后续处理，也不进行产品复位操做以保证当前正接通的用户能继续进行通话，系统的资源泄漏也无论，直到系统资源泄漏到不能提供任何一个服务为止再复位。

从ERROR_CP_NOCHANNEL错误的可能处理来看，不是仅有错误码的定义就完事了，而是须要从应用的层面定义好每种（不必定是每一个）错误出现时的处理逻辑是什么。这里所例举的呼叫处理错误，其实在一个产品中的任一个模块均可能存在相相似的问题，只是形式变了。而面对一个错误，其具体的应对方法每每须要考虑不少因素，有时面对的有多是两难问题。若是一个项目没有定义好各种错误的大体处理思路，而是彻底由程序员本身去思考，那仍是会致使程序员的个体思考成本太高这一问题，并且没有统一出错处理思路的指导，不一样程序员所作出来的出错处理方法有可能就会是相悖的，其结果就是另外一种混乱局面出现了！另外，即便定义了项目的出错处理思路，那这些出错逻辑是放在哪里处理呢？是将其分散在程序的各模块呢？仍是集中处理？若是是分散处理则有可能出现大量的冗余代码，且可能存在必定的困难。由于有些错误的处理，须要获得不少其它的信息，若是分散在程序的各处，那么意味着这些信息须要很大程度的公开，这会形成程序的结构出现必定的退化。笔者的观点是，究竟采用分散仍是集中处理方式并无绝对，但应当以集中出错处理为主。在后面笔者将会写一篇文章志门阐述出错处理方法，到时读者能够看到更为深刻的一些内容。

至此，程序员不按常识进行函数返回值的判断的深层次缘由分析过了，那要解决这一问题显然不能经过将“判断函数返回值”这几个字经过使用初号字体打印出来并贴在程序员的办公桌显眼处这一方式加以解决。出错处理其实不是程序员的我的私事，而是项目的集体事。要根本解决它，应当从项目全局的角度去着手。如下几点项目组能够考虑去作：
1) 从项目的层面定义好一个错误的表达方式是什么。一般，在C程序中须要定义错误码，而在C++中须要定义异常，固然在《错误管理》一文中也介绍了能够经过将二者结合起来作以简化错误表达。
2) 从项目的层面定义好各大类错误的处理思路和方法。另外，在项目团队中还要打造一种探讨出错处理思路和方法的氛围，这样更容易在团队中集思广义造成共识，从而为这些方法的实施铺平道路。
3) 在设计层面提供必定的错误处理机制以帮助减小程序出错时的代码工做量，这能有效的促进程序员积极面对函数的错误返回值。

不管如何，要造成一种敢于面对函数出错和积极思考出错处理方法的文化对于项目团队来讲不是一件容易事，但却很是重要。另外，有这方面的意识比没有要好，重视比不重视要好，固然作比不作又要更好。