从调试角度加上
}catch(Exception e){
e.printStackTrace();
}
在console窗口会看到异常的详细信息。一般来说最上面打印的是产生异常的根源出错class
你可能是初学java，处理异常时要养成习惯。有三个原则将会帮助你更好的使用异常即：具体化、早throw及晚Catch。要搞清楚错误是什么？什么地方发生错误？为什么发生错误？
比如说，Java的IO包定义了继承于 Exception的IOException类，更特殊一点就是FileNotFoundException，EOFException,， ObjectStreamException和所有的IOException的子类。每个异常类都描述了一种特定的与IO有关的错误，它们分别表示：文件丢失，文件意外结束，或者一个被破坏的序列化对象流。异常类越具体，对回答程序发生了什么错误就越有帮助。这也就是为什么要将异常类分类，以此让每个类特定地代表一种程序错误的原因？同时也是为什么在方法声明中throws某个特定的异常类，而不是如： throw Exception?也是为什么要在Catch中捕获具体的异常对象，而不是形如：try{}catch(Excetion e ){}的原因？
具体化就是要尽量明确try{}catch中间可能出现的Exception类型。
所谓具体化为：定义具体的代表某个特定错误的异常类。方法声明特定的异常类。方法捕获具体类。目地：具体问题具体处理。
早抛出
通过Stack trace向我们展示的引起异常的方法调用顺序、类名、方法名、原代码文件名以及每个方法调用的行号，这样可以帮助我们精确地定位异常发生的地方。因为比较早的抛出了异常，所以异常就变得更加具体和准确了。Stack trace也很准确地反映出发生了什么异常，为什么及在什么地方。这样使得Stacktrace更加准确的反映了本来程序所发生的一切：
晚捕获
许多Java开发人员，无论新手或老手都普遍地犯一个错误就是在程序有能力处理一个异常之前就将它捕获了。Java编译器坚持让Checked Exception不是要被捕获就一定要在函数头中声明的作法也客观上促使了程序员采用上面这一错误作法。对程序员来说，一个很自然的趋势就是让代码包括在try程序块中并捕捉异常以阻止编译器报错。问题是当捕获到异常之后你该如何处理它了？最坏的事情就是不做任何处理。一个空的catch块使异常无端地消失了从而使得关于异常的What、Where、Why信息永远丢失了。将异常的信息Log下来使情况稍好点，毕竟那样还有关于异常信息的记录。但是我们不可能期望用户想看甚至看懂Log文件和Stack trace信息。
其实晚捕获的意思可以这么理解：如果try{}catch一个Exception之后不做任何处理，还不如不处理，最好在一个统一的层面统一处理Exception。
有时候，开发人员直接捕获Exception，然后显示异常类的名字和Stack Trace信息，但为了具体问题具体处理，请不要这样做。看到屏幕上的Java.io.EOFException或者Stack Trace信息可能会使用户迷惑，而不是帮助他。捕获具体的异常从而用英语或其它语言给用户一个与问题相关提示,同时将异常的Stack Trace放到LOG文件中。异常和Stack Trace对开发人员意味着一个有力的调试工具，而对用户却毫无用处。
java捕获异常是要开发人员自己规定捕获哪些具体的异常的。不知道你想捕获异常后做什么？如果只是打印错误信息的话那么运行时异常jvm是可以帮我们自动捕获的，开发人员是可以不用显示的去编写捕获代码的，如果是可控异常那么就要显示的去写的，一般MyEclipse开发工具会帮开发人员自动添加上的。
是可以用 instanceof啊，我们项目也是这样用的。也有catch不同的exception的。
看看java API
用instanceof可以
if (e instanceof NullPointerException) {}
标签：Java,Exception,种类
