1700448571
1700448572
}
1700448573
1700448574
此时doStuff方法的友好性极差：出现异常时（比如文件不存在），该方法会直接把FileNotFoundException异常抛出到上层应用中（或者是最终用户），而上层应用（或用户）要么自己处理，要么接着抛，最终的结果就是让用户面对着“天书”式的文字发呆，用户不知道这是什么问题，只是知道系统告诉他“哦，我出错了，什么错误？你自己看着办吧”。
1700448575
1700448576
解决办法就封装异常，可以把异常的阅读者分为两类：开发人员和用户。开发人员查找问题，需要打印出堆栈信息，而用户则需要了解具体的业务原因，比如文件太大、不能同时编写文件等，代码如下：
1700448577
1700448578
public static void doStuff2（）throws MyBussinessException{
1700448579
1700448580
try{
1700448581
1700448582
InputStream is=new FileInputStream（“无效文件.txt”）；
1700448583
1700448584
}catch（FileNotFoundException e）{
1700448585
1700448586
//为方便开发和维护人员而设置的异常信息
1700448587
1700448588
e.printStackTrace（）；
1700448589
1700448590
//抛出业务异常
1700448591
1700448592
throw new MyBussinessException（e）；
1700448593
1700448594
}
1700448595
1700448596
}
1700448597
1700448598
（2）提高系统的可维护性
1700448599
1700448600
来看如下代码：
1700448601
1700448602
public void doStuff（）{
1700448603
1700448604
try{
1700448605
1700448606
//do something
1700448607
1700448608
}catch（Exception e）{
1700448609
1700448610
e.printStackTrace（）；
1700448611
1700448612
}
1700448613
1700448614
}
1700448615
1700448616
这是很多程序员容易犯的错误，抛出异常是吧？分类处理多麻烦，就写一个catch块来处理所有的异常吧，而且还信誓旦旦地说“JVM会打印出栈中的出错信息”，虽然这没错，但是该信息只有开发人员自己才看得懂，维护人员看到这段异常时基本上无法处理，因为需要深入到代码逻辑中去分析问题。
1700448617
1700448618
正确的做法是对异常进行分类处理，并进行封装输出，代码如下：
1700448619
1700448620
public void doStuff（）{
[
上一页 ]
[ :1.700448571e+09 ]
[
下一页 ]