人在江湖：如何用代码保护好自己

能做的事情中
第三 应该排第一。。人的问题是最麻烦的，用技术去解决人的问题，不现实，与其担惊受怕，为何不离开？

看下下，这个方法拦截器确定不错，谢谢！

公司不咋地，推诿貌似看上去很多

撇下业务不说，代码比较乱。。。
另外：良好重构的代码，是不需要过多的注释。

对的,这才是良好的习惯啊.

个人感觉，从纯技术角度上看，楼主的做法其实属于治标不治本，实在是丑陋的架构和管理手法下不得已采用的丑陋做法。

从风险一的应对措施来看，这段代码一次性不管三七二十一把所有Exception都catch起来，加上了一段没有任何业务语义的描述 （An error occured during XXX之类，如果方法名称起得好的话，从异常的调用栈里就能得到同样的信息。如果你觉得这种异常信息有用，有三种可能：1. 你打算让这条异常一直抛到用户界面上去，显示异常信息。或者 2.你所在的团队没有仔细看异常调用栈的习惯。或者 3.你们的代码类名和方法名起得不知所谓。） ，然后包装成另一个Unchecked Exception抛出来。正常来说，只要在架构的高层位置有一个大的try catch统一来干这个事情，这里就根本不用管。

通用的异常处理应该放在高层，通常底层代码是不用管更底层的代码抛出的RuntimeException的，除非：
1. 你有处理这个异常的具体方法（也就是在你的层面看，这个根本不是异常，而是业务的一部分）。
2. 你认为这段代码的调用者有能力处理这个异常，你就应该把这个异常封装成一个Checked Exception再抛出去。
3. 你为这个异常加入更具业务语义的message再抛出去。

从发现错误的角度看，一前一后两个log已经解决所有问题了，这里的异常处理纯属多余。除非，你的上层代码把异常吃掉了（既没日志又没继续往上抛），这纯属是做架构的人胡闹，害人不浅（如果你能拿到他们的代码，把吃异常的地方找出来，追究责任时可以拿来说事）。

不过就算是上层代码不可控，楼主也应该在可控的范围内把这种通用的异常处理往高层放，不用在底层搞那么多层层叠叠的try catch。

第二个风险的应对也不是正路，你开了新线程去调别人的东西，超时了你的线程就异常终止了，另一条线程还在跑呀（就算你强行kill了这条新线程，你也不知道黑箱里有没有再开新线程，或者通过异步方式干其他东西，例如读写数据库之类），它跑的结果怎么样，有没有什么副作用你都不管了。你这个异常终止之后，整个系统就处于一种未知状态了，后面的操作还怎么做，干脆直接Runtime.exit()再重新启动还安全一点。

既然别人的包本来预期是同步使用的，而且你不知道它的运行细节，把它强行改为异步没什么好处。如果你怕别人的包死锁，一般来说也是一前一后两个log就能发现问题了。感觉你在这里有点贪心，除了想发现错误，还想搞点错误恢复，但异步调用不能这么简单处理的。但如果要处理好，成本太高了。

从管理角度看，也很有问题：

1. 自己人的代码还搞什么黑箱。我一般都要求程序员如果调用不是自己写的接口，至少要往下看三层实现代码，包括别人的代码和开源代码。如果要修改代码，需要先往上找出所有调用关系并阅读代码，保证不会修改了一条调用路径上的bug却把另外的调用路径搞死了。如果是黑箱代码（我所在的项目基本没有），除非有完善的技术支持或者口碑非常好，否则一律不用，而且调用黑箱代码的前后必须做好日志。违反者一经发现，口头鄙视。

2. 找人负责也不是不行，但也不能老板越过技术主管直接找程序员的麻烦吧。不懂技术（甚至懂技术，但不了解具体上下文）的人直接批评程序员，往往只找到了表面现象就开骂（例如楼主说的李四），等到找到真正原因，又挂不住面子，反而更不爽你。楼主举的例子，我想象的场景是这样的：老板问张三，你这个语音模块怎么回事，这么卡。张三就说，具体不清楚，不过我调用了李四的包，可能跟这个有关系（典型的推卸责任）。然后老板就问李四，你怎么回事，李四说具体不清楚，能不能告诉我怎样重现错误，我调试一下（典型的认真负责）？老板一个笔记本拍李四脸上：去死吧你，就是你这个害群之马，人头猪脑。。。。（省略一百字）。这种搞法怎么能管好技术团队？

好在楼主说是上一家公司，估计已经脱离苦海了吧，恭喜恭喜。

=======================================
补充一点。。。
我本来想这种方法调用的日志其实最好用debug或trace级别，放在info级别，岂不是逼人在生产环境下关闭info级别的日志（我循环调用一个黑箱方法100次就会看到200条重复的日志，再来50个用户并发访问。。。）。不过后来想想也有道理，这里的日志不是为了查错，而是为了在第一时间撇清责任，等到发现错误再打开日志就太晚了。所以说丑陋的管理导致丑陋的代码。。。

很喜欢这样的帖子，谈谈我的观点。
从技术角度上:
1. 内部调用可以通过约定，大家都是白盒，避免使用无用的try/catch。外部调用的业务异常尽量提前约定好，不要自己猜测；系统级别异常根据情况决定是否捕获，是否有必要继续向上层抛出。外部调用日志信息要记录完整，便于线上问题定位。
2. 猎狗模式是一种好的远程调用方式，对于经常出问题的服务提供方，可以这样做防御性编码。但是如果每处调用都这么写，那太蛋疼了。

从管理上:
1. 出问题后，要对事不对人。大呼大叫，赶人，这是下下策。这样大家都战战兢兢，人心迟早要散的。出问题后，通过分析找到深层次原因，可以让当事人做案例分享，让其他同学从中吸取经验教训，防止后人犯同样错误。长期坚持下去，可以积累一份“经验教训宝典”，让大家定期学习，减少犯同类错误概率。
2. 工作中鼓励大家大胆写代码，不要怕犯错误，对于不合理的代码能够及时重构。

在位一天，就要尽最大努力去改变。如果你改变不了，还是乘早闪人。

供别人调用的代码不写javadoc吗？

应该配合拦截器机制使用，否则因为对方的异常、死锁或者更多的隐患而为对方补漏。代价实在太大了。

确实以前更多地是考虑逻辑啊业务啊什么的，对代码安全的敏感度还不够，以后对对接型代码的时候要多加考虑，感谢楼主啊。