Java提供了两类主要的异常:runtime exception和checked exception。所有的checked exception是从java.lang.Exception类衍生出来的，而runtime exception则是从java.lang.RuntimeException或java.lang.Error类衍生出来的。

一、机制上

它们在机制上的不同表现在两点:1.如何定义方法;2. 如何处理抛出的异常。

• Runtime exceptions:
  在定义方法时不需要声明会抛出runtime exception;
  在调用这个方法时不需要捕获这个runtime exception;
  runtime exception是从java.lang.RuntimeException或java.lang.Error类衍生出来的。
• Checked exceptions:
  定义方法时必须声明所有可能会抛出的checked exception;
  在调用这个方法时，必须捕获它的checked exception，不然就得把它的exception传递下去;
  checked exception是从java.lang.Exception类衍生出来的。

二、逻辑上

从逻辑的角度来说，checked exceptions和runtime exception是有不同的使用目的的。checked exception用来指示一种调用方能够直接处理的异常情况。而runtime exception则用来指示一种调用方本身无法处理或恢复的程序错误。

checked exception迫使你捕获它并处理这种异常情况。以java.net.URL类的构建器(constructor)为例，它的每一个构建器都会抛出MalformedURLException。MalformedURLException就是一种checked exception。设想一下，你有一个简单的程序，用来提示用户输入一个URL，然后通过这个URL去下载一个网页。如果用户输入的URL有错误，构建器就会抛出一个exception。既然这个exception是checked exception，你的程序就可以捕获它并正确处理:比如说提示用户重新输入。

总而言之，在程序的运行过程中一个checked exception被抛出的时候，只有能够适当处理这个异常的调用方才应该用try/catch来捕获它。而对于runtime exception，则不应当在程序中捕获它。如果你要捕获它的话，你就会冒这样一个风险:程序代码的错误(bug)被掩盖在运行当中无法被察觉。因为在程序测试过程中，系统打印出来的调用堆栈路径(StackTrace)往往使你更快找到并修改代码中的错误。有些程序员建议捕获runtime exception并纪录在log中，我反对这样做。这样做的坏处是你必须通过浏览log来找出问题，而用来测试程序的测试系统(比如Unit Test)却无法直接捕获问题并报告出来。

针对 RuntimeException 类型的异常， javac 是无法通过编译时的静态语法检测来判断到底哪些函数(或哪些区域的代码)可能抛出这类异常(这完全取决于运行时状态，或者说运行态所决定的)理解为non_checked可以？，也正因为如此， Java 异常处理模型中的“ must be caught or declared to be thrown ”规则也不适用于 RuntimeException (所以才有前面所提到过的奇怪编译现象，这也属于特殊规则吧)。但是， Java 虚拟机却需要有效地捕获并处理此类异常。当然， RuntimeException 也可以被程序员显式地抛出，而且为了程序的可靠性，对一些可能出现“运行时异常( RuntimeException )”的代码区域，程序员最好能够及时地处理这些意外的异常，也即通过 catch(RuntimeExcetion) 或 catch(Exception) 来捕获它们。

总结：

所有异常的根类为java.lang.Throwable,Throwable下面又派生了两个子类：Error和Exception。error表示恢复不是不可能但很困难情况下的一种严重的问题。比如说内存溢出，不可能指望程序处理这样的情况，exception表示一种设计或实现问题，也就是说，它表示如果程序运行正常，从不会发生的情况。

异常表示程序运行过程中可能出现的非正常状态，运行时异常表示虚拟机的通常操作中可能遇到的异常，是一种常见的运行错误。java编译器要求方法必须声明抛出可能发生的非运行时异常，但是并不要求必须声明抛出为被捕获的运行时异常。