摘要：
应该在以下情况使用异常: 1.)在恰当的级别处理问题.(在知道如何处理的情况下才捕获异常) 2.)解决问题并且重新调用异常的方法 3.)进行少许的修补,然后绕过异常发生的地方继续执行 4.)用别的数据进行计算,以代替预计返回的值 5.)把当前运行环境下能做的事情尽量做完,然后把相同的异常重新抛到高层 阅读全文
摘要：
Integer -> String String -> Integer 阅读全文
摘要：
一.当我们不知道该怎么处理这个异常,但是也不想把它"吞"了,或者打印一些无用的信息,可以使用异常链的思路解决.可以直接报"被检查的异常"包装进RuntimeException里面,就像这样: 这种技巧给了你一种选择,你可以不写try-catch子句或异常说明,直接忽略异常,让它自己沿着调用栈往上冒泡 阅读全文
摘要：
最简答而又不用写多少代码就能保护异常信息的方法,就是把它们从main()传递到控制台,对于简单的程序可以像这样: 通过把它传递到控制它这里就不必写try-catch子句了. 阅读全文
摘要：
异常起源于PL/1和Mesa之类的系统中. 1.) 不在于编译器是否会强制程序员去处理错误,而是要由一致的,使用异常来报告错误 2.) 不在于什么时候进行检查,而是一定要有检查. 阅读全文
摘要：
异常处理的一个原则时,只有当你在知道如何处理的情况下才捕获异常,异常处理的一个重要目标时将错误处理代码同错误发生的地点相分离. "被检查异常"强制你在还没准备好处理错误的时候被迫加上catch子句,这就导致了吞食则有害的问题.异常被吞食了. 阅读全文
摘要：
抛出异常的时候,异常处理系统会安装代码书写顺序找出"最近"的处理程序. 找到匹配的程序后,它就认为异常将得到清理,然后就不再继续查找. 查找的时候并不要求抛出的异常同处理程序的异常完全匹配.派生类的对象也可以配备其基类的处理程序 换句话说,捕获基类的异常,就可以匹配所有派生类的异常 阅读全文
摘要：
有一点很重要,即你要时刻询问子句"如果异常发生了,所有东西能被正确清理码?",尽管大多数情况下时非常安全的,但涉及到构造器时,问题出现了,构造器会把对象设置成安全的初始状态,但还会又别的动作,比如打开一个文件,这样的动作只有在对象使用完毕并且用户调用了特殊的清理方法之后才能得以清理,如果在构造器内抛 阅读全文
摘要：
一. 1.) 在覆盖方法的时候,只能抛出在基类方法的异常说明里列出的那些异常 2.) 在基类构造器声明的异常,在子类必须抛出,子类的构造器可以抛出任何异常,但是必须抛出基类构造器的异常 3.) 在基类和接口方法声明的异常,子类覆盖的方法可以不抛出基类和接口方法声明的异常以外的异常,但可以少或不抛出 阅读全文