1.对于异常的处理，之前是没有好好思考的。以前的做法是，基本不自定义异常对象，把系统要求处理的异常记录日志，少量地方偶尔想起时会使用系统自带的异常。在hmd时在一些地方使用过一种粗暴的处理，就是在action结束时，捕获一次Exception，如果出错则提示前台出现出错。
之前这些习惯不好的地方在于 a.如果只是把异常记录到日志，那么线上环境出问题时只能通过日志来查询。而实际开发中，开发人员不一定能方便访问到线上日志，且日志内容一般会很大。这么做就会导致出现了问题，也捕获了异常，但是又定位不到异常信息。很糟糕
b.捕获一次Exception提示传前台的出现了错误，其实也是一个糟糕的处理。因为当时并没有记录日志，也没有把具体错误提示给前台。这样对用户虽然友好一些，但是出了问题，基本没法复查。
c.比较理想的方式应该是，操作日志和异常日志分离。异常日志记录异常编号以及错误信息，异常反馈前端错误编号。而且对于web项目，这种错误机制最好由底层框架直接实现，而开发时，只需要抛出异常就可以（这是最理想的，因为这样既能方便定位又便于查询且对用户还友好 写了一个基于struts2的简单框架模型 ，SimpleThrowable）。
2.Java使用异常来提供一致的错误报告模型。
3.C++的异常处理机制基于ADa，Java的异常处理则建立在C++的基础之上。
4.异常最重要的方面质疑就是如果发生问题，他们不允许程序沿着其正常的路径继续走下去
5.Throwable这个Java类被用来表示任何可以作为异常被抛出的类。Throwable对象分两种类型：Error用来表示编译时和系统错误（除特殊情况外不需要关心）；Exception是可以被抛出的基本类型，在Java类库、用户方法以及运行时故障中都可能抛出Exception型异常。
6.RuntimeException。有很多由Java虚拟机抛出的，基于RuntimeException的异常。他们不需要被捕获。如果RuntimeException没有被捕获而直达main()，那么在程序退出前将调用异常的printStackTrace()方法。
7.finally清理的资源包括：已经打开的文件或网络连接，在屏幕上画的图形等
8.对于C#而言，“仅从小程序来看，会认为异常说明能增加开发人员的效率并提高代码质量；但考察大项目时，结论就不同了-开发效率下降了，而代码质量只得到微不足道的提高，甚至毫无提高”。思考所处理的项目是否存在同样的问题。（我理解的异常的目的在于提高代码质量、方便定位问题）
9.一种可以参考的完整的文件流打开关闭写法
FileInputStream in;
try {
in = new FileInputStream(file);
try {
int size = in.available();
byte[] buffer = new byte[size];
in.read(buffer);
str = new String(buffer, "GB2312");
} catch (IOException e) {
e.printStackTrace();
} finally {
try {
in.close();
} catch (IOException e) {
e.printStackTrace();
}
}
} catch (FileNotFoundException e1) {
e1.printStackTrace();
}
代码格式贴过来不友好。核心其实在于，流对象打开时(in = new FileInputStream(file);)一层处理，这里只处理流对象抛出的错误。因为出错了流对象就无需关闭。然后在使用流对象的过程中做一层处理，这层处理中，在finally块中关闭流对象。（看起来不友好的地方在于关闭时也需要处理一层）。
第12章 通过异常处理错误
12.1 概念
12.2 基本异常
12.2.1. 异常参数
12.3 捕获异常
12.3.1 try块
12.3.2. 异常处理程序
12.4 创建自定义异常
12.4.1 异常与记录日志
12.5 异常说明
12.6 捕获所有异常
12.6.1 栈轨迹
12.6.2 重新抛出异常
12.6.3 异常链
12.7 Java标准异常
12.7.1 特例：RuntimeException
12.8 使用finally进行清理
12.8.1 finally用来做什么
12.8.3 缺憾：异常丢失
12.9 异常的限制
12.10 构造器
12.11 异常匹配
12.12 其他可选方式
12.12.1 历史
12.12.2 观点
12.12.3 把异常传递给控制台
12.13 异常使用指南
12.14 总结
网友评论