如果不想心惊肉跳，那就至少对异常友善一些！

   昨天下午发生了让一堆人神经紧绷的状况。

   客户企业的仓库一下午无法获取出库凭证，零配件无法出库，车间停工，数个人的手机打爆，好几个开发人员连着服务器找问题，仓储系统人员急得像热锅上的蚂蚁，车间停工一天的损失就可能超过了整个项目的额度。

    解决问题已经接近晚上11点，而罪魁祸首竟是一条“不合规范”的日期数据—1011-01-21。（SQL Server2000不能处理1900年以前的日期数据）

    凭证 数据，是利用第三方给的接口函数从第三方数据库中获取过来的。整个下午，似乎都无法确定问题的位置。而这一点简直是致命性的。

    当然，我们可能会埋怨客户方的工作人员怎么如此疏忽，将日期输成了1011年；同样，我们也可能损微软几句：“看人家Oracle就能处理这个数据，你就不行。”。但扪心自问，谁能保证不出错呢？关键点是我们对待错误的态度。

    说到这里，又不得不提异常处理机制了。显然，以前做的仓储系统也是没有异常处理机制的，所以这样的日期值异常，就像幽魂般，悄悄地来，然后一声不响的又走了，不留下一丝足迹。而要捕捉它，只能去数据的大海里苦苦的追索。

    程序似乎并没有出错，就客户方工作人员来说，似乎也不可能会意识到自己的“一键之差”能酿成的巨大损失，但事实就这么样发生了。既然发生了，我们能做的只能是尽快找到问题点，并让整个的业务恢复到正常运作。从这一点来说，异常信息的处理至关重要。当然，导致问题发生的可能性有很多，但异常的完善处理至少可以避免或减轻大部分类似的小型灾难。

    写了这么多，是真的第一次认识到对异常信息的捕捉和记录的重要性，如果放任他们的发生和流逝，我想，在将来系统的运行期间，总是避免不了心惊肉跳的经历。有时候朦朦胧胧睡梦中问自己，他们用这样的系统时，会不会有如履薄冰的感觉？在系统里流淌的可都是正儿八经的钞票。