简单的异常处理方式能让我们更有精力做好其他事

    最近工作中还真的遇到比较多的问题，线上出现了异常，一时间还真不好处理，花了大半天做了临时方案后，该想想这些问题以后怎样避免了。

    当然，线上的问题或多或少是会出现的，好的结果是可以很简单的以最小成本的方式去解决，但大部分往往都是到了上线出现了故障才知道这样做并不是最好的。

    今天出现的代码问题，其实算是非常简单的，调用了外部接口，然后接口异常，接着应用处理失败。是的，在开发环境下是再简单不过的事了，可是回头想想，如果发布到线上了，每个步骤都必须严格走发布流程的时候，这可是件头大的事情了。

如何用最简单的方式去规避或者恢复这类问题，在写代码的时候真的需要考虑下，个人觉得有这么三个小点可以参考下：

1、异常时仍可用机制：  
在自己的应用中出现异常时，如使用了第三方的接口或者外部应用，在第三方出现问题时，如超时，不可连接，数据出错等，自动切换为默认业务可允许的结果返回，避免这类应用影响到自己的正常处理逻辑，这类可以规划为异常时仍可用机制。

2、异常时可模拟过程工具：
  同样，普遍的处理流程都是很直观的，A需要依赖B事件，B事件需要依赖C事件，一连串的触发后最终才有处理后的结果，但如果出现异常时，当中的某一事件出错了，事件流不可再继续的情况下，要么就等着客户投诉，要么就紧急的手忙脚乱的找了一大堆人做了数据订正，花了大半天才能解决一个重要但不是最紧急的问题，反而忘了堵住问题的源头，这样无形中时间的浪费是非常可怕的。这个时候，如果能有自己的工具，模拟其中的某些过程，好吧，异常出现了吧，那我就先订正下，其他时间重点花在解决问题根源上，OK，这样不就省事多了吗？这其实是种很好的解决问题的手段之一，说成业务的后门也不为过。

3、异常后数据订正工具：  
   和2中其实很类似的，异常出现后，往往有时候会带着业务数据的出错，不可再回滚问题，如业务做了一半，这个时候，需要清除掉这部分数据可以说真的是非常非常的头痛了，一个点涉及到十几张表的时候更加不可想象，怎么办呢？想想2中的后门，数据订正的后门也是一个非常棒的工具，可以根据现在的业务，自动的修正掉错误的数据，何乐而不为呢？

说了那么多，其实最重要的核心并不是如何去解决异常后的问题，而是在编码阶段就应该考虑各种异常的情况，做到尽量考虑到可能的问题和解决的方式，那才是做最正确的事。