java的哲学之一就是要让糟糕的代码也可以运行
Exception需要强制处理的是非编译期的 CheckException
不强制要求处理的是 RuntimeException
错误的理想处理时间是编译期,但是不是所有的错误都可以在编译期检测到的,这些错误就需要通过某些形式把错误的发生点和相关信息传递给恰当的接收者来处理
从错误中恢复对于每个程序来说都是一个基本要求(健壮性),但健壮性对java来说更为重要,因为它的主要目标就是编写程序组件供他人使用。
C和其他一些早期的语言提供多种错误处理策略,而且都不作为语言的一部分,而只是作为惯例。长此以往发现两个问题,
- 程序员没有积极性去处理错误,那些调用别人编写的库的程序员总认为出错是编写者那里出问题了。
- 以 编写错误处理代码会降低程序健壮性和可读性为理由不去编写处理错误代码。
而java设计者把异常处理作为语言的一部分强制程序员对错误异常进行处理
这就减少了许多可以避免的错误异常,提高了程序的健壮性(当然如果对于捕获的异常仅仅是在catch中输出错误信息甚至连信息都不输出,那异常处理机制基本没发挥作用甚至准备了一个深坑)
另一个好处是降低错误处理代码的复杂度,你不需要检查特定的错误和在很多地方处理错误。有了异常机制你只需要在某个地方处理错误就可以了,这样就可以做到错误处理代码和正常代码分离,有更好的可读性维护性。
当你遇到一个异常(Exception)程序便无法在当前的方法继续执行,你必须跳出当前的Context并递交问题到高层次的Context。
当你抛出一个异常,将会发生以下事情
1. 异常对象会被创建,跟其他java对象一样通过new创建在堆上
2. 当前的执行会被中断异常对象的引用会从当前Context弹出。
此时异常处理机制接管程序并开始寻找一个合适的地方继续执行程序,这个合适的地方就是EXception handler(catch),它负责从问题中恢复程序,然后寻找另一条路径或者继续执行
throw 抛出异常 让你不用在当前处理问题 把问题抛给调用者处理
throws 声明方法可能会出现的异常 提醒调用者在调用的时候进行适当的异常处理
try..catch (finally)对异常进行处理
Exception允许你把所有你做的事情当做事务,并且有很多回滚点,如果程序中的一部分出错了,可以回滚到程序中一个已知的稳定点
在你的代码中只有RuntimeException是可以被忽视的
RuntimeException代表无法预知的错误,但一个错误,你作为一个程序员应该对你的代码进行过检查。
finally段是用来在虚拟机回收内存之前对一些资源进行清理的的操作,虚拟机只负责内存回收
部分内容还没能看懂