11.3 使用异常机制的建议 （1）异常处理不能代替简单的测试。不发生异常时，不要try…catch,这个过程非常耗时。 （2）不要过分细化异常。每句话写一个try…catch 没必要（内心OS:正常人
11.3 使用异常机制的建议
（1）异常处理不能代替简单的测试。不发生异常时，不要try…catch,这个过程非常耗时。
（2）不要过分细化异常。每句话写一个try…catch 没必要（内心OS:正常人不会这么写吧？）
（3）利用异常层次结构。不要只抛出 RuntimeException 异常，适当维护子类（貌似我们还真会这么干，因为不用每层都try…catch,清爽多了，有时候我懒得写直接抓Exception）。个人建议，如果自定义，一定要很清晰的分清楚哪种异常代表什么含义，否则下一个人接手只会让异常类别越来越不搭。我个人（浅薄）看法其实这里区分不如实际日志输出的内容重要。
（4）不要抑制异常。如果一个位置，基本不可能出现异常就不要catch它。（实际上我们公司所有的模块外层最终都用try…catch包裹了，不希望处理系统莫名的宕机问题，有问题就让它不起作用，但缩小它的危害，不要降低软件风评，降低不良影响）
（5）检测错误时，要尽量严格。比如一段输出日志内容的拼接串，当前传入前已经保证数据正确性。但是有了足够的检查，后续扩展时就很难发生难以预计的错误。（非常赞同。其实有时候是习惯问题，所有输入，好的代码都要怀疑传入数据的正确性，和所有可能产生的错误类型。）
（6）不要羞于传递异常
有的时候抛出比捕获更好。比如小明考试提交的考卷有一道题写错了。好的做法是告诉他错了，坏的做法是不批改（小明下次还是不知道怎么做，还会拿着考卷问你这题对的错的）。
11.4 断言
通常进行数值检查发生错误时，会直接抛出异常。可考虑在数据检查时，使用断言
这个属性要配一下，-ea
断言测试：
public class Main {public static void main(String[] args) {
Main solution = new Main();
solution.init(-5);
}
public void init(int a){
assert a >= 0;
}
}
换一句再试试（断言发生错误时输出冒号后面的值）：
assert a >= 0:a;
相关内容：选择 《Java核心技术 卷1》查找相关笔记
评论