1700449393
1700449394
try{
1700449395
1700449396
FileInputStream fis=new FileInputStream（file）；
1700449397
1700449398
/*其他业务逻辑处理*/
1700449399
1700449400
}catch（FileNotFoundException e）{
1700449401
1700449402
//异常处理
1700449403
1700449404
}
1700449405
1700449406
}
1700449407
1700449408
这样一段代码经常会在我们的项目中出现，但经常写并不代表不可优化，这里的异常类FileNotFoundException完全可以在它诞生前就消除掉：先判断文件是否存在，然后再生成FileInputStream对象，代码如下：
1700449409
1700449410
public static void main（String[]args）{
1700449411
1700449412
File file=new File（“文件.txt”）；
1700449413
1700449414
//经常出现的异常情况，可以先做判断
1700449415
1700449416
if（fle.exists（）＆＆！fle.isDirectory（））{
1700449417
1700449418
try{
1700449419
1700449420
}catch（）{
1700449421
1700449422
}
1700449423
1700449424
}
1700449425
1700449426
}
1700449427
1700449428
虽然增加了if判断语句，增加了代码量，但是却会减少FileNotFoundException异常出现的几率，提高了程序的性能和稳定性。
1700449429
1700449430
注意 异常只为确实异常的事件服务。
1700449431
1700449432
1700449433
1700449434
1700449436
编写高质量代码：改善Java程序的151个建议 建议117：多使用异常，把性能问题放一边
1700449437
1700449438
我们知道异常是主逻辑的例外逻辑，举个简单例子来说，比如我在马路上走（这是主逻辑），突然开过一辆车，我要避让（这是受检异常，必须处理），继续走着，突然一架飞机从我头顶飞过（非受检异常），我可以选择继续行走（不捕捉），也可以选择指责其噪音污染（捕捉，主逻辑的补充处理），再继续走着，突然一颗流星砸下来，这没有选择，属于错误，不能做任何处理。这样具备完整例外情景的逻辑就具备了OO的味道，任何一个事物的处理都可能产生非预期结果，问题是需要以何种手段来处理，如果不使用异常就需要依靠返回值的不同来进行处理了，这严重失去了面向对象的风格。
1700449439
1700449440
我们在编写用例文档（Use Case Specification）时，其中有一项叫作“例外事件”，是用来描述主场景外的例外场景的，例如用户登录的用例，就会在“例外事件”中说明“连续3次登录失败即锁定用户账号”，这就是登录事件的一个异常处理，具体到我们的程序中就是：
1700449441
1700449442
public void login（）{
[
上一页 ]
[ :1.700449393e+09 ]
[
下一页 ]