java中checked和unchecked异常的区别

• 什么是unchecked异常?

即RuntimeException （运行时异常）
不需要try...catch...或throws 机制去处理的异常

• 列举最常用的五种RuntimeException:    

这是JAVA认证考试中最常见的题目,事实上,runtime exception中最常见的,经常碰到的,也就5,6种,如下:

ArithmeticException	int a=0; int b= 3/a;
ClassCastException：	Object x = new Integer(0); System.out.println((String)x);
IndexOutOfBoundsException     ArrayIndexOutOfBoundsException,     StringIndexOutOfBoundsException	int [] numbers = { 1, 2, 3 }; int sum = numbers[3];
IllegalArgumentException     NumberFormatException	int a = Interger.parseInt("test");
NullPointerExceptionextends

• 除了RuntimeException，其他继承自java.lang.Exception得异常统称为Checked Exception,他们有多少种呢?

下面是JDK API中列出的异常类:

除了RuntimeException以外的,都是checked Exception

java.lang.Object   java.lang.Throwable       java.lang.Exception 所有已实现的接口： Serializable 直接已知子类： AclNotFoundException, ActivationException, AlreadyBoundException, ApplicationException, AWTException, BackingStoreException, BadAttributeValueExpException, BadBinaryOpValueExpException, BadLocationException, BadStringOperationException, BrokenBarrierException, CertificateException, ClassNotFoundException, CloneNotSupportedException, DataFormatException, DatatypeConfigurationException, DestroyFailedException, ExecutionException, ExpandVetoException, FontFormatException, GeneralSecurityException, GSSException, IllegalAccessException, IllegalClassFormatException, InstantiationException, InterruptedException, IntrospectionException, InvalidApplicationException, InvalidMidiDataException, InvalidPreferencesFormatException, InvalidTargetObjectTypeException, InvocationTargetException, IOException, JAXBException, JMException, KeySelectorException, LastOwnerException, LineUnavailableException, MarshalException, MidiUnavailableException, MimeTypeParseException, MimeTypeParseException, NamingException, NoninvertibleTransformException, NoSuchFieldException, NoSuchMethodException, NotBoundException, NotOwnerException, ParseException, ParserConfigurationException, PrinterException, PrintException, PrivilegedActionException, PropertyVetoException, RefreshFailedException, RemarshalException, RuntimeException, SAXException, ScriptException, ServerNotActiveException, SOAPException, SQLException, TimeoutException, TooManyListenersException, TransformerException, TransformException, UnmodifiableClassException, UnsupportedAudioFileException, UnsupportedCallbackException, UnsupportedFlavorException, UnsupportedLookAndFeelException, URIReferenceException, URISyntaxException, UserException, XAException, XMLParseException, XMLSignatureException, XMLStreamException, XPathException

使用checked exceptions引起以下一些问题:
1. 代码膨胀. 程序员必须书写代码捕获并忽略那些他们并不能合理地加以处理的异常, 他们将变得很泄气. 这是一种糟糕的编程实践, 经验表明它们发生得比我们想象的更为频繁. 即使是一个好的程序员也会偶尔忘记正确地将异常嵌套, 这意味着完整的调用栈将丢失, 异常中包含的信息就不再那么有用.
2. 代码的可读性降低. 在例程中捕获那些不能合理加以处理的异常并马上重新抛出它们, 使得很难找到那些真正做一些事情的代码. Java的正统观点认为这一点只困扰那些懒惰的程序员, 我们应该简单地忽略这个问题. 然而, 这种观点忽略了事实. 例如, 设计Java核心库的人显然清楚地考虑过这个问题. 想象一下, 如果象java.util.Iterator这样的界面抛出checked exceptions而不是unchecked exceptions, 那么使用它们将是一场噩梦. JDO API是另外一个来自Sun自己的API的例子, 它使用unchecked exceptions. 相反, JDBC使用checked exceptions, 使用起来就很笨重.
3. 没完没了地包装异常. 一个checked exceptions必须被捕获, 或者声明在可能遇到它们的那些方法的异常规范中. 这就造成一种选择, 可以重新抛出异常, 也可以将一个低级别的异常包装在一个新的高级别异常中, 然后重新抛出. 如果我们加入了一些有用的信息, 包装并重新抛出异常是很值得的. 但是, 如果原来的异常是不可恢复的, 包装它们就毫无价值. 如果使用unchecked exceptions, 在这种情况下将引起一个自动的栈回绕, 而使用checked exceptions, 我们无非做了一个等价的手工栈回绕, 并且在调用栈路径上的每一个方法中都要添加一些额外的毫无意义的代码, 只是为了包装异常. 主要是这个原因才促使我重新思考自己关于异常处理的态度.
4. 脆弱的原型声明. 如果很多代码都使用了某个界面, 那么要声明一条额外的异常规范就会导致修改大量代码.
5. 定义接口时, Checked exceptions并不总是工作得那么良好. 考虑Java教程中文件系统满的例子. 如果我们谈论的是一个使用文件系统的类, 这个例子没有问题. 如果我们处理的是一个仅仅承诺在某处(也许是数据库)存储数据的类, 情况又怎样呢? 我们肯定不想在这个类的接口中硬编码进对Java I/O API的依赖, 因为这个接口很可能有许多不同的实现. 若使用checked exceptions, 我们必须为这个接口创建一个新的存储介质无关的异常类型, 并且将文件系统异常包装其中. 这样做是否值得依赖于发生的异常是不是可恢复的. 如果不可恢复, 我们又一次做了无用功.

很多这些问题归结于这样一个问题: 我们捕获了一个无法处理的异常, 被迫重新抛出一个包装过的异常. 这很讨厌, 很容易引起错误(因为很容易丢失调用栈), 并且没有用. 此时使用unchecked exceptions更佳. Unchecked exceptions会引发自动的栈回绕, 而且也是在发生致命错误时的正确行为.

文章来源：http://blog.csdn.net/sweetsoft/article/details/569498

http://blog.sina.com.cn/s/blog_6151984a0100kgbv.html