【編程好習慣】判斷函數的返回值

調用一個函數後要檢查函數的返回值，以決定程序是繼續應用邏輯處理仍是出錯處理，這理應是一個常識，但在現實中，卻存在大量不檢查函數返回值的代碼。既然是常識，但卻得不到重視，這不能簡單地說程序員不知道其危害性。相信讀者也明白不檢查函數的返回值其危害是什麼，所以，也不打算舉例說明其所帶來的問題，而是試圖去探究程序員爲何不按這一常識去作。

要判斷函數的返回值，不可避免地要面對一個問題 —— 出錯了怎麼辦？這顯然不是一個簡單的問題，在這問題的背後多是在問：在項目中一個錯誤如何表達？項目是否認義了出錯處理的準則或機制？

若是一個項目沒有一種有效的方法表達一個錯誤，那麼就會出現對於出錯處理的混亂情況。當出現錯誤時，僅僅經過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) 在設計層面提供必定的錯誤處理機制以幫助減小程序出錯時的代碼工做量，這能有效的促進程序員積極面對函數的錯誤返回值。

不管如何，要造成一種敢於面對函數出錯和積極思考出錯處理方法的文化對於項目團隊來講不是一件容易事，但卻很是重要。另外，有這方面的意識比沒有要好，重視比不重視要好，固然作比不作又要更好。