Java异常处理实例分析 处理办法。java的异常处理机制里面，含有两种异常处理方式，第一种是throw往外抛异常，第二种是try…catch…方式捕获java异常处理异常。那么，何时用throw什么时候又用try….catch…处理呢？
有些初学者，只要是遇到java异常处理他们几乎都是使用try…catch…，也就是所什么异常他们都捕获处理，但是很多都在catch语句块里面还是选择用throw new Exception(e);使用语句将异常往外抛。事实上我是不赞同这中做法的。我的理解是这样的在java程序中，异常的处理应该是严谨一点的比较好，就算不可以十分完善地把异常处理好，也应尽量地把我们写java程序有可能的异常处理好了，这样后来的用户或者以后自己代码重用的时候，也方便处理。
java异常分两种大的异常类型，运行异常以及受检查异常，这两种异常的区别如下：
1、java运行时异常
运行异常的特点为Java编译器不去检查它，换句话说，程序中可能出现这类异常时，就算没有使用try…catch语句捕获它、该异常，也不用throws字句声明抛出它，但是还是会编译通过。
2、java受检查异常
除了java运行异常外，别的java异常都属于受检查异常，这类异常的特点是不是用try…catch捕获处理，那么就是throws语句声明抛出，否则编译不会通过。
3、两者的区别：
运行异常是无法让程序恢复运行的异常，引起这种java异常的原因一般是因为执行了错误的操作。一旦出现错误，最好让程序终止。
java受检查异常是程序可以处理的异常。假如抛出异常的方法本身不处理或不能处理它，那方法的调用者就一定要去处理该异常，不然调用会出错，连编译也不能通过。然而，这两种java异常都是能够通过程序来捕获并处理的。
对于java运行异常，最好不要用try…catch…捕获处理，应该在程序开发调试的过程中尽量的避免，当然有一些必须要处理的，自己知道了那个部分会出现异常，而这种异常你要把它处理的你想要的结果，如：空值处理。
而java受检查的异常，编译的时候不可以通过，只能老老实实的用throw或者try..catch…来处理，那么用什么情况下用那种方式呢？看下面的例子：
public static Connection getConn(){
try {
Connection conn =
DriverManager.getConnection(url,user,pwd);
return conn;
} catch (SQLException e) {
return null;
}
}
明显的出现一个问题就是，出现了受检查的异常直接用try…catch…捕获，可是这种捕获基本上没有什么有用的意义，还不如用throw抛出去的好直接告诉调用者，这个方法会出现SQLException，不然调用者用这个方法结果返回了一个null，就不知道发生了什么事。
事实上在try…catch…语句块中，一般的受检查异常是很难在自己方法内处理的，但如果出现了异常怎么办，一般的做法是在catch语句块中用og4j记录异常，给后台工作人员。
java异常处理的原则上是，可以自己处理的就不往上抛，尽量把java异常细化不要什么异常都直接用Exception来代替，在一个try语句块中尽量少的异常。
1.检查型异常,这样的异常继承于Excetpion，在编译期间需要检查,假如该异常被throw,那在该异常所在的method之后必须显示的throws,调用该method的地方也必须捕获该异常,否则编译器会抛出异常.ejb里的RemoteException是一个这样的异常.
2.java运行时异常,就是在运行期间系统出现的异常,该类异常继承于RuntimeException,该类异常在编译时系统不进行检查,如NullPointerExcetpion,NumberFormatException.
3.系统错误,一般是JVM出现异常时抛出的异常,例如OutofMemoryError,这样的异常在J2EE开发中是不用太关心的.
J2EE开发中,检查型异常被滥用导致过一段时间程序员自己都看不明白抛出这样的异常,.里头封装的这些错误信息是干什么用的,更可怕的是有好多有用的信息找不到了.比如SQLException和RemoteException这样的异常我们没必要再进行封装,这样的异常只对我们调试程序有用,而对客户来说它就是一个”系统错误”而已.异常处理有一个简单的原则,什么时候需要封装自己的检查型异常?就是你很清楚自己抛出这个异常的用途时,比如用户输入用户名和密码要登录,但用户名和密码不匹配,你就要定义一个检查型异常,客户端通过捕获该异常,然后把相应的错误信息反馈给客户.而其它的自己未预期的错误或者异常比如SQLException,只需封装到EJBException中,ejb container会把它的信息追加到RemoteException里,这样客户端捕获RemoteException后把它写到系统日志里,就很容易进行调试。
Java 异常的处理
Java 应用程序中，对异常的处理有两种方式：处理异常和声明异常。
处理异常：try、catch 和 finally
若要捕获异常，则必须在代码中添加异常处理器块。这种 Java 结构可能包含 3 个部分，
都有 Java 关键字。以下的例子中使用了 try-catch-finally 代码结构。
import java.io.*;
public class EchoInputTryCatchFinally
{
public static void main（String args［］）
{ System.out.println（”Enter text to echo：”）;
InputStreamReader isr = new InputStreamReader（System.in）;
BufferedReader inputReader = new BufferedReader（isr）;
try{ String inputLine = inputReader.readLine（）;
System.out.println（”Read：” + inputLine）; } catch（IOException exc）{ System.out.println（”Exception encountered： ” + exc）; } finally{ System.out.println（”End. “）; } } 其中：
try 语句块：将一个或者多个语句放入 try 时，则表示这些语句可能抛出异常。编译器知道可能要发生异常，于是用一个特殊结构评估块内所有语句。
catch 块：当问题出现时，一种选择是定义代码块来处理问题，catch 块的目的便在于此。catch 块是 try 块所产生异常的接收者。基本原理是：一旦生成异常，则 try 块的执行中止，JVM 将查找相应的 JVM。
finally 块：还可以定义 finally 块，无论运行 try 块代码的结果如何，该块里面的代码一定运行。在常见的所有环境中，finally 块都将运行。无论 try 块是否运行完，无论是否产生异常，也无论是否在 catch 块中得到处理，finally 块都将执行。
try-catch-finally 规则：
必须在 try 之后添加 catch 或 finally 块。try 块后可同时接 catch 和 finally 块，但至少有一个块。
必须遵循块顺序：若代码同时使用 catch 和 finally 块，则必须将 catch 块放在 try 块之后。
catch 块与相应的异常类的类型相关。
一个 try 块可能有多个 catch 块。若如此，则执行第一个匹配块。
可嵌套 try-catch-finally 结构。
在 try-catch-finally 结构中，可重新抛出异常。
除了下列情况，总将执行 finally 做为结束：JVM 过早终止（调用 System.exit（int））；在 finally 块中抛出一个未处理的异常；计算机断电、失火、或遭遇病毒攻击。
声明异常
若要声明异常，则必须将其添加到方法签名块的结束位置。下面是一个实例：
public void errorProneMethod（int input） throws java.io.IOException { //Code for the method，including one or more method //calls that may produce an IOException } 这样，声明的异常将传给方法调用者，而且也通知了编译器：该方法的任何调用者必须遵守处理或声明规则。声明异常的规则如下：
必须声明方法可抛出的任何可检测异常（checked exception）。
非检测性异常（unchecked exception）不是必须的，可声明，也可不声明。
调用方法必须遵循任何可检测异常的处理和声明规则。若覆盖一个方法，则不能声明与覆盖方法不同的异常。声明的任何异常必须是被覆盖方法所声明异常的同类或子类。
本文链接地址: Java异常处理实例分析 throw与try…catch…处理办法的选择