[程序员] 最近的感悟，错误处理占大头？

根据昨天分享的一个问题，想到的。

在代码里，异常处理的代码也算是占大头，扑面而来的就是发生错误时怎么处理的大片代码；而且出现问题的概率是绝对的占大头。所以，异常代码出现bug的概率也在不知不觉中增加！

昨天遇到的这个例子：[程序员] 网络丢包的另一个例子：send失败是不是要close socket？。就是一个很好的说明，这里就是一个非常极端的例子，收发两端的buff都满了，这种情况出现的概率非常低；最终触发错误处理代码逻辑中的不合理，导致上层业务数据丢。但是这种不合理，又没有什么好的正向解决的方法（或者是一直不close，慢慢等buff清空，但是又要考虑是否有安全问题），导致最终的解决方法是不确定的，需要根据具体的需求，具体实现！

或者是将buff的size增大，减少出现buff慢的概率，然后容忍这种低概率事件的存在。或者是上层实现更加可靠的传输。或者是等待的时间拉长，也是容忍这种高概率事件的发生。

所以新产品虽然在实验室的环境中，跑着没有问题；但是并不代表安装到客户现场就一定没问题，因为异常出现的本质就是意想不到！谁能知道客户现场的网络能有这么差！导致产品内部各种异常处理出现问题/不能恢复！谁知道客户买的硬件会有缺陷，磁盘读取非常的慢，导致程序不能按时处理完成某项业务，导致产品问题！谁又能想到客户网络对接的网元实现与实验室的行为不一致，导致不兼容！谁又能知道客户技术员是如此的较真，只要不顺手，什么都可以称之为问题！等等不一而足。不知道大家有没有遇到过此类的事件？

这些都是超出研发想象的一些异常问题。所以即使在研发内部已经预想到了很多的异常可能，加了很多的异常代码，但是保不住还有没有想到的异常在客户现场等着你！即使想到了某种异常，而加了异常处理代码，到了现场，或许会因为异常处理代码的加入，而引入其他的问题。