第7章 异常、断言和日志
异常
在Java中，所有异常对象都是派生于Throwable类的一个实例。
如果Java内置的异常类不能够满足需求，用户可以创建自己的异常类
Error类层次结构描述了Java运行时系统的内部错误和自愿耗尽错误，应用程序不应该抛出这种类型的对象。
Exception层次结构又分解为两个分支，一个分支派生于RuntimeException；另一个分支包含其他异常。
划分这两个分支的规则为：
由程序错误导致的异常属于RuntimeException；
程序本身没有问题，但由于像I/O错误这类问题导致的属于其它异常
一般来说，属于RuntimeException的有：
- 错误的类型转换
- 数组访问越界
- 访问null指针
正所谓，“如果出现RuntimeException异常，那么就一定是你的问题。”
不属于RuntimeException的异常有：
- 试图在文件尾部后面读取数据
- 试图打开一个不存在的文件
Java将派生于Error类或RuntimeException类的所有异常称为非受查异常，所有其他的异常称为受查异常
而编译器将核查是否为所有的受查异常提供了异常处理器
一个方法不仅需要告诉编译器要返回什么值，还要告诉编译器有可能发生什么错误
一个方法必须声明所有可能抛出的受查异常，而非受查异常要么不可控制(Error)，要么应该避免发生(RuntimeException)
如果方法没有声明所有可能发生的受查异常，编译器就会发出一个错误信息，使用throws关键字声明受查异常
使用throw关键字抛出异常。此时，只将异常作为对象抛出，不对其进行处理。
抛出一个已经存在的异常类非常容易，
若是遇到任何标准异常类都没有能够充分地描述清楚的问题，就需要创建自己的异常类，
即定义一个派生于Exception的类或者派生于Exception子类的类。
如果某个异常发生时没有在任何地方进行捕获，那程序就会终止执行，并在控制台上打印出异常信息。
要想捕获异常必须要设置try/catch语句块
在一个try语句块中可以捕获多个异常类型，每个异常类型使用一个单独的catch子句
而在catch子句中也可以再次抛出异常，这么做的目的是为了改变异常的类型
不管有无异常被捕获，finally子句的代码都会被执行
使用异常机制的技巧：
- 只在异常情况下使用异常机制，不可用作测试
- 不要过分地细化异常;如不要将一条语句封装在一个独立地try语句中
- 利用异常层次;不要只抛出RuntimeException，要寻找更加适当的子类或创建自己的异常类
- 不要压制异常；在Java中，往往强烈地倾向于关闭异常
- 在检查错误时，“苛刻”要比放任好
- 不要羞于传递异常
断言
断言机制允许在测试期间想代码插入一些检查语句。当代码发布时，这些插入的测试语句将被自动地移走
Java引入了关键字assert，对应的有两种形式
assert 条件;
assert 条件:表达式;
这两种形式都会对条件进行检测，若结果为false，则抛出一个AssertError异常。
在第二种形式中，表达式将会被传入AssertError的构造器，并转换成一个消息字符串
在默认情况下，断言被禁用，需要开启。
什么时候使用断言呢？
- 断言失败是致命的，不可恢复的错误
- 断言检查只用于开发和测试阶段。断言只应该用于在测试阶段确定程序内部的错误。
记录日志
每个Java程序员都很熟悉在有问题的代码中插入System.out.println方法调用来帮助观察程序运行的过程，
而一旦发现问题的根源，就要将这个打印语句删除。若其他地方还有问题，则需要重复这种写打印语句又删除的行为。
而记录日志则提供了一种更为科学的方法。
要生成简单的日志记录，可以使用全局日志记录器并调用其info方法:
Logger.getGlobal().info("File->Open menu item seleceted");
但是在适当的地方（如main开始）调用
Logger.getGlobal.setLevel(Level.OFF);
就会取消所有的日志。
在一个专业的应用程序中，不要将所有的日志都记录到一个全局日志记录器中，而是可以自定义日志记录器
可以调用getLogger方法来创建或者获取记录器
private static final Logger myLogger = Logger.getLogger("com.mycompany.myapp");
用一个静态变量存储日志记录器的引用
记录日志的常见用途是记录那些不可预料的异常
原文地址：https://www.cnblogs.com/ASE265/p/12240801.html