锁定老帖子 主题:人在江湖:如何用代码保护好自己
该帖已经被评为良好帖
|
|
---|---|
作者 | 正文 |
发表时间:2011-10-14
学到很多,很有收获,感谢楼主分享经验···
|
|
返回顶楼 | |
发表时间:2011-10-14
留个退路!
|
|
返回顶楼 | |
发表时间:2011-10-14
楼主说的这个问题,确实需要重视,至少在查找错误,定位错误的时候可以提高效率,同时保证了程序的健壮性
|
|
返回顶楼 | |
发表时间:2011-10-14
kidneyball 写道 个人感觉,从纯技术角度上看,楼主的做法其实属于治标不治本,实在是丑陋的架构和管理手法下不得已采用的丑陋做法。
从风险一的应对措施来看,这段代码一次性不管三七二十一把所有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个用户并发访问。。。)。不过后来想想也有道理,这里的日志不是为了查错,而是为了在第一时间撇清责任,等到发现错误再打开日志就太晚了。所以说丑陋的管理导致丑陋的代码。。。 讲的很有道理。冰冻三尺非一日之寒,研发管理的不正规肯定在这个公司存在了很多年,之前肯定有人提过建议,改进措施,为什么还这样子?我想这种现象已经在公司形成了一种风气,很难改变。当我们无力去改变时,只有二种选择了 一是去适应、二是离开。 |
|
返回顶楼 | |
发表时间:2011-10-14
sunnylocus 写道 zhanghh321 写道 真是要这么做么,那岂不是每调用一个方法都要加try catch么? 我对这个不是很了解, 麻烦楼主说下哦
当然不是,每个方法都要加try catch没有必要,关键的方法上要加,比如说调用别人的充值、转账、记账方法时要加的,金融系统出错,就会涉及到钱。我们目的是万一调用别人的代码出错,我们可以用try catch捕获,在日志中记录下来,他们找茬就拿日志理论,出错是因为我调用别人的代码出错了不是我的原因,如果你的代码没有捕获,日志里也没有错误记录,你有理也说不清。 明显王五的方法不抛checke异常,那王五方法内部的checke异常要么已经被处理了,要么转化为unchecked异常,作为此方法的调用者来说,如果对可能出现的unchecked异常没兴趣或者无法处理的话,最好的方法就是继续上抛,顶层的调用者正常情况下会做统一处理的。LZ的方法仅仅是做个日志的话,感觉没啥大的必要。 |
|
返回顶楼 | |
发表时间:2011-10-14
这个事情,也得具体问题具体分析,老板娘出来大呼小叫的,算什么啊,这样的公司趁早走,呵呵,没前途!!
|
|
返回顶楼 | |
发表时间:2011-10-14
有一定现实性,不过感觉很消极。。。
|
|
返回顶楼 | |
发表时间:2011-10-14
aa00aa00 写道 这个事情,也得具体问题具体分析,老板娘出来大呼小叫的,算什么啊,这样的公司趁早走,呵呵,没前途!!
200w |
|
返回顶楼 | |
发表时间:2011-10-14
aa00aa00 写道 这个事情,也得具体问题具体分析,老板娘出来大呼小叫的,算什么啊,这样的公司趁早走,呵呵,没前途!!
老板娘发飙是因为老板娘也是公司的董事之一,分管系统运营这块,出了问题能不大呼小叫么。 |
|
返回顶楼 | |
发表时间:2011-10-14
很有收获!!很有感触! 感谢LZ!!
|
|
返回顶楼 | |