根據(jù)昨天分享的一個問題，想到的。

在代碼里，異常處理的代碼也算是占大頭，撲面而來的就是發(fā)生錯誤時怎么處理的大片代碼；而且出現(xiàn)問題的概率是絕對的占大頭。所以，異常代碼出現(xiàn)bug的概率也在不知不覺中增加！

昨天遇到的這個例子：[程序員] 網(wǎng)絡丟包的另一個例子：send失敗是不是要close socket？。就是一個很好的說明，這里就是一個非常極端的例子，收發(fā)兩端的buff都滿了，這種情況出現(xiàn)的概率非常低；最終觸發(fā)錯誤處理代碼邏輯中的不合理，導致上層業(yè)務數(shù)據(jù)丟。但是這種不合理，又沒有什么好的正向解決的方法（或者是一直不close，慢慢等buff清空，但是又要考慮是否有安全問題），導致最終的解決方法是不確定的，需要根據(jù)具體的需求，具體實現(xiàn)！

或者是將buff的size增大，減少出現(xiàn)buff慢的概率，然后容忍這種低概率事件的存在。或者是上層實現(xiàn)更加可靠的傳輸。或者是等待的時間拉長，也是容忍這種高概率事件的發(fā)生。

所以新產(chǎn)品雖然在實驗室的環(huán)境中，跑著沒有問題；但是并不代表安裝到客戶現(xiàn)場就一定沒問題，因為異常出現(xiàn)的本質就是意想不到！誰能知道客戶現(xiàn)場的網(wǎng)絡能有這么差！導致產(chǎn)品內(nèi)部各種異常處理出現(xiàn)問題/不能恢復！誰知道客戶買的硬件會有缺陷，磁盤讀取非常的慢，導致程序不能按時處理完成某項業(yè)務，導致產(chǎn)品問題！誰又能想到客戶網(wǎng)絡對接的網(wǎng)元實現(xiàn)與實驗室的行為不一致，導致不兼容！誰又能知道客戶技術員是如此的較真，只要不順手，什么都可以稱之為問題！等等不一而足。不知道大家有沒有遇到過此類的事件？

這些都是超出研發(fā)想象的一些異常問題。所以即使在研發(fā)內(nèi)部已經(jīng)預想到了很多的異常可能，加了很多的異常代碼，但是保不住還有沒有想到的異常在客戶現(xiàn)場等著你！即使想到了某種異常，而加了異常處理代碼，到了現(xiàn)場，或許會因為異常處理代碼的加入，而引入其他的問題。