1.RuntimeException
public class RuntimeException {
public static void main(String[] args) {
// TODO Auto-generated method stub
String str="123";
int temp=Integer.parseInt(str);
System.out.println(temp*temp);
}
}
查看parseInt方法的源代码如下：
public static int parseInt(String s) throws NumberFormatException {
return parseInt(s,10);
}
我们发现这个方法中抛出了NumberFormatException异常，但是在上面的代码中我们没有找到try...catch来处理，这是为什么呢。按照我们异常处理的知识，如果一个方法通过throws抛出了异常，那么可以在抛出异常的方法中不使用try...catch，但是在调用这个方法的地方必须有try...catch来处理。
下面来观察NumberFormatException类的继承关系：
从上图我们可以发现NumberFormatException是RuntimeException的子类，那么这就需要我们清楚Exception和RuntimeException的概念：
- Exception：在程序中必须使用try...catch进行处理。
- RuntimeException：可以不使用try...catch进行处理，但是如果有异常产生，则异常将由JVM进行处理。
对于RuntimeException的子类最好也使用异常处理机制。虽然RuntimeException的异常可以不使用try...catch进行处理，但是如果一旦发生异常，则肯定会导致程序中断执行，所以，为了保证程序再出错后依然可以执行，在开发代码时最好使用try...catch的异常处理机制进行处理。
Throwable是所有异常的基类，程序中一般不会直接抛出Throwable对象，Exception和Error是Throwable的子类，Exception下面又有RuntimeException和一般的Exception两类。可以把JAVA异常分为三类：
第一类是Error，Error表示程序在运行期间出现了十分严重、不可恢复的错误，在这种情况下应用程序只能中止运行，例如JAVA
虚拟机出现错误。Error是一种unchecked
Exception,编译器不会检查Error是否被处理,在程序中不用捕获Error类型的异常；一般情况下，在程序中也不应该抛出Error类型的异常。
第二类是RuntimeException, RuntimeException 是一种unchecked
Exception，即表示编译器不会检查程序是否对RuntimeException作了处理，在程序中不必捕获RuntimException类型的异常，也不必在方法体声明抛出RuntimeException类。RuntimeException发生的时候，表示程序中出现了编程错误，所以应该找出错误修改程序，而不是去捕获RuntimeException。
第三类是一般的checked
Exception,这也是在编程中使用最多的Exception,所有继承自Exception并且不是RuntimeException的异常都是checked
Exception，如图1中的IOException和ClassNotFoundException。JAVA 语言规定必须对checked
Exception作处理，编译器会对此作检查，要么在方法体中声明抛出checked Exception,要么使用catch语句捕获checked
Exception进行处理，不然不能通过编译。checked Exception用于以下的语义环境：
（1） 该异常发生后是可以被恢复的，如一个Internet连接发生异常被中止后，可以重新连接再进行后续操作。
（2）
程序依赖于不可靠的外部条件，该依赖条件可能出错，如系统IO。
（3） 该异常发生后并不会导致程序处理错误，进行一些处理后可以继续后续操作。
4
JAVA异常处理中的注意事项
合理使用JAVA异常机制可以使程序健壮而清晰，但不幸的是，JAVA异常处理机制常常被错误的使用，下面就是一些关于Exception的注意事项：
1． 不要忽略checked Exception
请看下面的代码：
try
{
method1();
//method1抛出ExceptionA
}
catch(ExceptionA e)
{
e.printStackTrace();
}
上面的代码似乎没有什么问题，捕获异常后将异常打印，然后继续执行。事实上在catch块中对发生的异常情况并没有作任何处理(打印异常不能是算是处理异常，因为在程序交付运行后调试信息就没有什么用处了)。这样程序虽然能够继续执行，但是由于这里的操作已经发生异常，将会导致以后的操作并不能按照预期的情况发展下去，可能导致两个结果：
一是由于这里的异常导致在程序中别的地方抛出一个异常，这种情况会使程序员在调试时感到迷惑，因为新的异常抛出的地方并不是程序真正发生问题的地方，也不是发生问题的真正原因；
另外一个是程序继续运行，并得出一个错误的输出结果，这种问题更加难以捕捉，因为很可能把它当成一个正确的输出。
那么应该如何处理呢，这里有四个选择：
（1） 处理异常，进行修复以让程序继续执行。
（2）
重新抛出异常，在对异常进行分析后发现这里不能处理它，那么重新抛出异常，让调用者处理。
（3）
将异常转换为用户可以理解的自定义异常再抛出，这时应该注意不要丢失原始异常信息（见5）。
（4） 不要捕获异常。
因此，当捕获一个unchecked
Exception的时候，必须对异常进行处理；如果认为不必要在这里作处理，就不要捕获该异常，在方法体中声明方法抛出异常，由上层调用者来处理该异常。
2． 不要一次捕获所有的异常
请看下面的代码：
try
{
method1();
//method1抛出ExceptionA
method2();
//method1抛出ExceptionB
method3();
//method1抛出ExceptionC
}
catch(Exception e)
{
……
}
这是一个很诱人的方案，代码中使用一个catch子句捕获了所有异常，看上去完美而且简洁，事实上很多代码也是这样写的。但这里有两个潜在的缺陷，一是针对try块中抛出的每种Exception，很可能需要不同的处理和恢复措施，而由于这里只有一个catch块，分别处理就不能实现。二是try块中还可能抛出RuntimeException,代码中捕获了所有可能抛出的RuntimeException而没有作任何处理，掩盖了编程的错误，会导致程序难以调试。
下面是改正后的正确代码：
try
{
method1(); //method1抛出ExceptionA
method2();
//method1抛出ExceptionB
method3();
//method1抛出ExceptionC
}
catch(ExceptionA e)
{
……
}
catch(ExceptionB e)
{
……
}
catch(ExceptionC e)
{
……
}
3． 使用finally块释放资源
finally关键字保证无论程序使用任何方式离开try块，finally中的语句都会被执行。在以下三种情况下会进入finally块：
（1）
try块中的代码正常执行完毕。
（2） 在try块中抛出异常。
（3）
在try块中执行return、break、continue。
因此，当你需要一个地方来执行在任何情况下都必须执行的代码时，就可以将这些
代码放入finally块中。当你的程序中使用了外界资源,如数据库连接，文件等，必须将释放这些资源的代码写入finally块中。
必须注意的是，在finally块中不能抛出异常。JAVA异常处理机制保证无论在任何情况下必须先执行finally块然后在离开try块，因此在try块中发生异常的时候，JAVA虚拟机先转到finally块执行finally块中的代码，finally块执行完毕后，再向外抛出异常。如果在finally块中抛出异常，try块捕捉的异常就不能抛出，外部捕捉到的异常就是finally块中的异常信息，而try块中发生的真正的异常堆栈信息则丢失了。
请看下面的代码：
Connection con = null;
try
{
con =
dataSource.getConnection();
……
}
catch(SQLException
e)
{
……
throw
e;//进行一些处理后再将数据库异常抛出给调用者处理
}
finally
{
try
{
con.close();
}
catch(SQLException
e)
{
e.printStackTrace();
……
}
}
运行程序后，调用者得到的信息如下
java.lang.NullPointerException
at
myPackage.MyClass.method1(methodl.java:266)
而不是我们期望得到的数据库异常。这是因为这里的con是null的关系，在finally语句中抛出了NullPointerException,在finally块中增加对con是否为null的判断可以避免产生这种情况。
4． 异常不能影响对象的状态
异常产生后不能影响对象的状态，这是异常处理中的一条重要规则。
在一个函数
中发生异常后，对象的状态应该和调用这个函数之前保持一致，以确保对象处于正确的状态中。
如果对象是不可变对象(不可变对象指调用构造函数创建后就不能改变的对象，即
创建后没有任何方法可以改变对象的状态)，那么异常发生后对象状态肯定不会改变。如果是可变对象，必须在编程中注意保证异常不会影响对象状态。有三个方法可以达到这个目的：
（1）
将可能产生异常的代码和改变对象状态的代码分开，先执行可能产生异常的代码，如果产生异常，就不执行改变对象状态的代码。
（2）
对不容易分离产生异常代码和改变对象状态代码的方法，定义一个recover方法，在异常产生后调用recover方法修复被改变的类变量，恢复方法调用前的类状态。
（3）
在方法中使用对象的拷贝，这样当异常发生后，被影响的只是拷贝，对象本身不会受到影响。
5． 丢失的异常
请看下面的代码：
public void
method2()
{
try
{
……
method1(); //method1进行了数据库操作
}
catch(SQLException
e)
{
……
throw new
MyException(“发生了数据库异常:”+e.getMessage);
}
}
public void
method3()
{
try
{
method2();
}
catch(MyException e)
{
e.printStackTrace();
……
}
}
上面method2的代码中，try块捕获method1抛出的数据库异常SQLException后，抛出了新的自定义异常MyException。这段代码是否并没有什么问题，但看一下控制台的输出：
MyException:发生了数据库异常：对象名称
‘MyTable‘ 无效。
at MyClass.method2(MyClass.java:232)
at
MyClass.method3(MyClass.java:255)
原始异常SQLException的信息丢失了，这里只能看到method2里面定义的MyException的堆栈情况；而method1中发生的数据库异常的堆栈则看不到，如何排错呢，只有在method1的代码行中一行行去寻找数据库操作语句了，祈祷method1的方法体短一些吧。
JDK的开发者们也意识到了这个情况，在JDK
1.4.1中，Throwable类增加了两个构造方法,public Throwable(Throwable cause)和public
Throwable(String message,Throwable
cause)，在构造函数中传入的原始异常堆栈信息将会在printStackTrace方法中打印出来。但对于还在使用JDK1.3的程序员，就只能自己实现打印原始异常堆栈信息的功能了。实现过程也很简单，只需要在自定义的异常类中增加一个原始异常字段，在构造函数中传入原始异常，然后重载printStackTrace方法，首先调用类中保存的原始异常的printStackTrace方法，然后再调用super.printStackTrace方法就可以打印出原始异常信息了。可以这样定义前面代码中出现的MyException类：
public
class MyExceptionextends Exception
{
//构造函数
public SMException(Throwable
cause)
{
this.cause_ = cause;
}
public MyException(String s,Throwable
cause)
{
super(s);
this.cause_ =
cause;
}
//重载printStackTrace方法，打印出原始异常堆栈信息
public void
printStackTrace()
{
if (cause_ !=
null)
{
cause_.printStackTrace();
}
super.printStackTrace(s);
}
public void printStackTrace(PrintStream
s)
{
if
(cause_ != null)
{
cause_.printStackTrace(s);
}
super.printStackTrace(s);
}
public void printStackTrace(PrintWriter
s)
{
if
(cause_ != null)
{
cause_.printStackTrace(s);
}
super.printStackTrace(s);
}
//原始异常
private Throwable cause_;
}
6． 不要使用同时使用异常机制和返回值来进行异常处理
下面是我们项目中的一段代码
try
{
doSomething();
}
catch(MyException e)
{
if(e.getErrcode ==
-1)
{
……
}
if(e.getErrcode ==
-2)
{
……
}
……
}
假如在过一段时间后来看这段代码，你能弄明白是什么意思吗？混合使用JAVA异常处理机制和返回值使程序的异常处理部分变得“丑陋不堪”，并难以理解。如果有多种不同的异常情况，就定义多种不同的异常，而不要像上面代码那样综合使用Exception和返回值。
修改后的正确代码如下：
try
{
doSomething(); //抛出MyExceptionA和MyExceptionB
}
catch(MyExceptionA
e)
{
……
}
catch(MyExceptionB e)
{
……
}
总结一下，
java运行时异常是可能在java虚拟机正常工作时抛出的异常。
java提供了两种异常机制。一种是运行时异常(RuntimeExepction)，一种是检查式异常(checked
execption)。
检查式异常：我们经常遇到的IO异常及sql异常就属于检查式异常。对于这种异常，java编译器要求我们必须对出现的这些异常进行catch
所以 面对这种异常不管我们是否愿意，只能自己去写一堆catch来捕捉这些异常。
运行时异常：我们可以不处理。当出现这样的异常时，总是由虚拟机接管。比如：我们从来没有人去处理过NullPointerException异常，它就是运行时异常，并且这种异常还是最常见的异常之一。
RuntimeExecption在java.lang包下，
下面是由java虚拟机提供的运行时异常
AnnotationTypeMismatchException,
ArithmeticException,
ArrayStoreException,
BufferOverflowException,
BufferUnderflowException,
CannotRedoException,
CannotUndoException,
ClassCastException,
CMMException,
ConcurrentModificationException,
DOMException,
EmptyStackException,
EnumConstantNotPresentException,
EventException,
IllegalArgumentException,
IllegalMonitorStateException,
IllegalPathStateException,
IllegalStateException,
ImagingOpException,
IncompleteAnnotationException,
IndexOutOfBoundsException,
JMRuntimeException,
LSException,
MalformedParameterizedTypeException,
MirroredTypeException,
MirroredTypesException,
MissingResourceException,
NegativeArraySizeException,
NoSuchElementException,
NoSuchMechanismException,
NullPointerException,
ProfileDataException,
ProviderException,
RasterFormatException,
RejectedExecutionException,
SecurityException,
SystemException,
TypeConstraintException,
TypeNotPresentException,
UndeclaredThrowableException,
UnknownAnnotationValueException,
UnknownElementException,
UnknownTypeException,
UnmodifiableSetException,
UnsupportedOperationException,
WebServiceException
看到这么多异常，想要找出我们常见的5中运行时异常是非常容易的。
例如：ClassCastException(类转换异常)
IndexOutOfBoundsException(数组越界)
NullPointerException(空指针)
ArrayStoreException(数据存储异常，操作数组时类型不一致)
还有IO操作的BufferOverflowException异常
1.throws
用于抛出方法层次的异常，
并且直接由些方法调用异常处理类来处理该异常，
所以它常用在方法的后面。比如
public
static void main(String[] args) throws SQLException
2.throw
用于方法块里面的代码，比throws的层次要低，比如try...catch ....语句块，表示它抛出异常，
但它不会处理它，
而是由方法块的throws
Exception来调用异常处理类来处理。
throw用在程序中，明确表示这里抛出一个异常。
throws用在方法声明的地方，表示这个方法可能会抛出某异常。
throw是抛出一个具体的异常类，产生一个异常。
throws则是在方法名后标出该方法会产生何种异常需要方法的使用者捕获并处理。
java异常——RuntimeException和User Define Exception