• [x] 一个方法被覆盖时，覆盖它的方法必须抛出相同的异常或异常的子类。如果父类抛出多个异常，则覆盖方法必须抛出那些异常的一个子集，不能抛出新异常。
• [x] 提倡异常的封装，可以提供系统的友好性，提高系统的可维护性，对异常进行分类，解决Java异常机制缺陷。进行异常封装 。

class MyException extends Exception{
    private List<Throwable> causes = new ArrayList<>();
    public MyException(List<? extends Throwable> causes){
        this.causes.add((Throwable) causes);
    }
    public List<Throwable> getException(){
        return causes;
    }
    public static void doStuff() throws MyException {
        List<Throwable> list = new ArrayList<>();
        try{
            //异常代码
        }catch(Exception e){
            list.add(e);
        }
        try{
            //异常代码
        }catch (Exception e){
            list.add(e);
        }
        if (list.size() > 0)
            throw new MyException(list);
    }
}

• [x] 异常只为异常服务，只针对异常的情况才使用异常，异常应该只用于异常的情况下;它们永远不应该用于正常的控制流。即异常块里不添加逻辑，添加逻辑会造成异常判断降低了系统性能，降低了代码可读性，隐藏了运行期可能产生的异常.
• [x] 多使用异常，把性能放一边，异常是主逻辑的例外逻辑，比如 在马路上走路(主逻辑)，突然开过一辆车，我要避让(受检异常，必须处理)，继续走路，突然一架飞机从我头顶飞过(非受检异常)，我可以选择走路(不捕捉)，也可以选择职责其噪音污染(捕捉，主逻辑的补充处理)，在继续走下去，突然一棵流星砸下类，这是没有选择，属于错误，不能做任何处理。
• [x] 不要在构造函数中抛出异常，一个对象的创建要经过内存分配，静态代码初始化，构造函数执行等过程，一般不在构造函数中抛出异常，是程序员无法处理的，会加重上层代码的编写者的负担，后续代码不会执行，违背了里氏替换原则，父类能出现的地方子类就可以出现，而且将父类替换为子类也不会产生任何异常， java的构造函数允许子类的构造函数抛出更广泛的异常类(正好与类方法的异常机制相反:子类方法的异常类型必须为父类方法的子类型，覆写要求)，当替换时，需要增加catch块，构造函数没有覆写的概念，只有构造函数之间的引用调用而已，同时子类构造函数扩展受限。
• [x] 使用Throwsable获得栈信息，AOP编程可以亲松的控制一个方法调用那些类，也能控制那些方法允许别调用，一般来讲切面编程只能控制到方法级别，不能实现代码级别的植入(Weave)，即不同类的不同方法参数相同调用相同方法返回不同的值。即要求被调用者具有识别调用者的能力，可以使用Throwable获得栈信息，然后鉴别调用者信息。

package com.liruilong.throwable_demo;

/**
 * @Classname Main
 * @Description TODO
 * @Date 2021/6/22 2:31
 * @Created Li Ruilong
 */
public class Main {
    public static void main(String[] args) {
      Invoker.m1();
      Invoker.m2();
    }
}
class Foo{
    public  static boolean m(){
        // 堆栈跟踪中的一个元素，由Throwable.getStackTrace()返回。 每个元素表示单个堆栈帧。
        // 堆栈顶部除堆栈之外的所有堆栈都表示方法调用。 堆栈顶部的帧表示生成堆栈跟踪的执行点。
        // 通常，这是创建与堆栈跟踪相对应的throwable的点。
        //取得当前栈信息
        StackTraceElement []  stackTraceElements = new Throwable().getStackTrace();
        //检查是否是m1方法调用
        for(StackTraceElement st: stackTraceElements){
            System.out.println(st);
            if(st.getMethodName().equals("m1"))
                return true;
        }
        return false;
        //throw new RuntimeException("除m1方法外，该方法不允许其他方法调用");
    }
}
class  Invoker{
    //该方法打印true
    public static void m1(){
        System.out.println(Foo.m());
    }
    //该方法打印false
    public  static void m2(){
        System.out.println(Foo.m());
    }
}

• [x] API设计中，对可恢复的情况使用受检异常,对编程错误使用运行时异常，如果期望调用者能够适当地恢复,对于这种情况就应该使用受检异常。通过抛出受检的异常,强迫调用者在一个catch子句中处理该异常,或者将它传播出去。用运行时异常来表明编程错误。你实现的所有未受检的抛出结构都应该是RuntimeException的子类(直接的或者间接的),
• [x] 避免不必要地使用受检异常，受检异常可以提升程序的可读性;如果过度使用,将会使API使用起来非常痛苦。如果调用者无法恢复失败,就应该抛出未受检异常。如果可以恢复,并且想要迫使调用者处理异常的条件,首选应该返回一个optional值。当且仅当万一失败时,这些无法提供足够的信息,才应该抛出受检异常。
• [x] 优先使用标准的异常,重用标准的异常有多个好处：
  • [x] 它使API更易于学习和使用,因为它与程序员已经熟悉的习惯用法一致。最主要的好处。
  • [x] 对于用到这些API的程序而言,·它们的可读性会更好,因为它们不会出现很多程序员不熟悉的异常。
  • [x] 异常类越少,意味着内存占用(footprint)就越小,装载这些类的时间开销也越少。最不重要的一点。

不要直接重用：Exception、 RuntimeException、 Throwable或者Error。对待"这些类要像对待抽象类一样。你无法可靠地测试这些异常,因为它们是一个方法可能抛出的其他异常的超类。

• [x] 抛出与抽象对应的异常
• [x] 每个方法抛出的所有异常都要建立文档,使用Javadoc的@throws标签记录下一个方法可能抛出的每个未受检异常,但是不要使用throws关键字将未受检的异常包含在方法的声明中。如果一个类中的许多方法出于同样的原因而抛出同一个异常,在该类的文档注释中对这个异常建立文档,这是可以接受的,而不是为每个方法单独建立文档。
• [x] 努力使失败保持原子性,作为方法规范的一部分,产生的任何异常都应该让对象保持在调用该方法之前的状态。如果违反这条规则, API文档就应该清楚地指明对象将会处于什么样的状态.
• [x] 不要忽略异常忽略一个异常很容易，空的catch块会使异常达不到应有的目的.如果选择忽略异常, catch块中应该包含注释,说明为什么可以这么做,并且变量应该命名为ignored: