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

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

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

严重的学习了。请问如果LZ创建的精灵线程发现超时后，会自动释放该精灵线程所占用的内存？假如这个精灵线程正在等待其他资源而引起了超时，该精灵线程是否会被销毁？

LZ 在代码上标志，画图，用的什么工具？

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

从风险一的应对措施来看，这段代码一次性不管三七二十一把所有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个用户并发访问。。。）。不过后来想想也有道理，这里的日志不是为了查错，而是为了在第一时间撇清责任，等到发现错误再打开日志就太晚了。所以说丑陋的管理导致丑陋的代码。。。