1700449436
编写高质量代码:改善Java程序的151个建议 建议117:多使用异常,把性能问题放一边
1700449437
1700449438
我们知道异常是主逻辑的例外逻辑,举个简单例子来说,比如我在马路上走(这是主逻辑),突然开过一辆车,我要避让(这是受检异常,必须处理),继续走着,突然一架飞机从我头顶飞过(非受检异常),我可以选择继续行走(不捕捉),也可以选择指责其噪音污染(捕捉,主逻辑的补充处理),再继续走着,突然一颗流星砸下来,这没有选择,属于错误,不能做任何处理。这样具备完整例外情景的逻辑就具备了OO的味道,任何一个事物的处理都可能产生非预期结果,问题是需要以何种手段来处理,如果不使用异常就需要依靠返回值的不同来进行处理了,这严重失去了面向对象的风格。
1700449439
1700449440
我们在编写用例文档(Use Case Specification)时,其中有一项叫作“例外事件”,是用来描述主场景外的例外场景的,例如用户登录的用例,就会在“例外事件”中说明“连续3次登录失败即锁定用户账号”,这就是登录事件的一个异常处理,具体到我们的程序中就是:
1700449441
1700449442
public void login(){
1700449443
1700449444
try{
1700449445
1700449446
//正常登录
1700449447
1700449448
}catch(InvalidLoginException lie){
1700449449
1700449450
//用户名无效
1700449451
1700449452
}catch(InvalidPsswordException pe){
1700449453
1700449454
//密码错误的异常
1700449455
1700449456
}
1700449457
1700449458
}catch(TooMuchLoginException tmle){
1700449459
1700449460
//多次登录失败的异常
1700449461
1700449462
}
1700449463
1700449464
}
1700449465
1700449466
如此设计则可以让我们的login方法更符合实际的处理逻辑,同时使主逻辑(正常登录,try代码块)更加清晰。当然了,使用异常还有很多优点,比如可让正常代码和异常代码分离、能快速查找问题(栈信息快照)等,但是异常有一个缺点:性能比较慢。
1700449467
1700449468
Java的异常处理机制确实比较慢,这个“比较慢”是相对于诸如String、Integer等对象来说的,单单从对象的创建上来说,new一个IOException会比String慢5倍,这从异常的处理机制上也可以解释:因为它要执行fillInStackTrace方法,要记录当前栈的快照,而String类则是直接申请一个内存创建对象,异常类慢一筹也就在所难免了。
1700449469
1700449470
而且,异常类是不能缓存的,期望预先建立大量的异常对象以提高异常性能也是不现实的。
1700449471
1700449472
难道异常的性能问题就没有任何可提高的办法了?确实没有,但是我们不能因为性能问题而放弃使用异常,而且经过测试,在JDK 1.6下,一个异常对象创建的时间只需要1.4毫秒左右(注意是毫秒,通常一个交易处理是在100毫秒左右),难道我们的系统连如此微小的性能消耗都不允许吗?
1700449473
1700449474
注意 性能问题不是拒绝异常的借口。
1700449475
1700449476
1700449477
1700449478
1700449480
编写高质量代码:改善Java程序的151个建议 第9章 多线程和并发
1700449481
1700449482
We’re here to put a dent in the universe.Otherwise why else even be here?
1700449483
1700449484
活着就是为了改变世界,难道还有其他原因吗?
[
上一页 ]
[ :1.700449435e+09 ]
[
下一页 ]