因为大部分的方法总是不能明确的知道如何处理异常，这就只能声明抛出异常，而这种情况又是如此普遍，所以Checked异常降低了程序开发的生产率和代码的执行率。关于Checked异常是利大于弊，还是弊大于利呢？

既然出了这么个东西，肯定是它存在的价值的。对于checked异常我有以下几点看法：
1、它可以对可能的异常的地方作一个强制的处理，即如果出现某些非致命错误，程序还是会能继续运行。比如，
关闭IO流。
2、异常可以将出错信息存储在堆栈里边，对于程序开发者而言，这无疑为我们顺藤摸瓜，找到错误的根源提供了
很大的帮助。

关于java的异常机制的讨论，已经很久了，有人批判java的异常处理就是个垃圾，后来java之父就开始叫板了！哎，公说公有理婆说婆有理呀！
我也不是高手，随便说说咯~
个人觉得，java引入checked异常只是让程序员多了一个选择，它并不强迫你使用checked异常。如果你对什么时候应该使用checked异常感到迷惑，那么最简单的办法就是，不要使用checked异常！
世间万物总是具有两面性，有好的一面必定也会有坏的一面。
假如你使用了checked异常，那么：
第一，你需要考虑更多的问题。首先在设计上就会更加复杂，其次就是代码更加冗长。设计上复杂体现在以下方面： 1 对异常（错误）的抽象和理解。你得知道什么情况才能算checked异常，使得上级确实能够处理（修复）这种异常，并且让整个程序从这种设计中确实得到好处。
2 对整个自定义checked异常继承体系的设计。总不能在一个方法后面抛出几十个异常吧！设计自定义checked异常，就要考虑方法问题，在合适的时候抛出合适的异常（不能一味的抛出最具体的异常，也不能一味抛出最抽象的异常）。
第二，业务代码相比较使用unchecked的情况而言，不够直接了当了。引入了throws和try catch，代码里有很多catch，方法也和异常绑定了。
第三，有了更强的错误处理能力。如果发生了checked异常，我们有能力处理（修复）它。表现在不是任何错误都会导致程序挂起，出现了checked异常，程序可能照样运行。整个程序更加健壮，而代价就是前面2条。
       总而言之，存在必有它的道理，如果你想日后更好的去维护你的程序，想让你的程序容错性更强，健壮性更强，在敲代码时你就得多费点功夫。java的异常机制恰如其分的反映了生活当中的一些道理：一分耕耘一分收获！付出总有回报的！

在多态中，成员函数的特点：
在编译时期：参阅应用型所属的类中是否有调用的方法。如果有编译通过否则便以失败。
在运行时期：参阅对象所属的类中是否有调用的方法。
总结：成员函数在多态调用时，编译看左边，运行看右边。

在多态中，成员变量的特点：
无论在编译和运行都参考左边（引用型变量所属的类）。


在多态中，静态成员函数的特点：
无论编译和运行，都参考左边。




把这些总结记住就行了~~

额········我回答错了·····发错帖了···不好意思    — —。

    到底利弊有多大，或者倒底什么时候使用checked异常，什么时候使用unChecked异常？并没有一个绝对的标准。

当所有调用者必须处理这个异常，可以让调用者进行重试操作；或者该异常相当于该方法的第二个返回值。使用checked异常。
这个异常仅是少数比较高级的调用者才能处理，一般的调用者不能正确的处理。使用unchecked异常。有能力处理的调用者可以进行高级处理，一般调用者干脆就不处理。
这个异常是一个非常严重的错误，如数据库连接错误，文件无法打开等。或者这些异常是与外部环境相关的。不是重试可以解决的。使用unchecked异常。因为这种异常一旦出现，调用者根本无法处理。
如果不能确定时，使用unchecked异常。并详细描述可能会抛出的异常,以让调用者决定是否进行处理！