异常捕获与抛出的问题，什么时候应该try，什么时候应该throws，有没有一个标准或者规范？
1.工具类里面throw
流程类里catch
2.上层不关心的异常就catch掉，自己处理。
上层关心的异常一般都throw
3.理论上讲，应该捕捉一切可以预知的异常。当然，如果不是最终的使用者（客户程序员），而是类库提供者，可以throws，因为你可以确知这些异常会最终被处理；否则，一定要谨慎的使用throws，因为可能最终exception不会被正确处理。
的确是有这样的特例的。比如，在jsp里，即使不处理异常也不抛出，因为jsp本身机制，也不会报编译错。这个时候，可能会使这个异常成为类似于RuntimeException的东西，让最终用户看到。这种做法是不负责任的。
RuntimeException只是一个概念，实际上，本来所有的Exception都一样，本质上RuntimeException不会另行处理。所以，是不是throws，还是要根据你的总体设计中bean所处的地位来进行判断。
catch(Exception e){
e.printStackTrace() ;
}
当try语句中出现异常是时，会执行catch中的语句，java运行时系统会自动将catch括号中的Exception e 初始化，也就是实例化Exception类型的对象。e是此对象引用名称。然后e（引用）会自动调用Exception类中指定的方法，也就出现了e.printStackTrace() ;。
printStackTrace()方法的意思是：在命令行打印异常信息在程序中出错的位置及原因。（这是白话解释，比较容易理解）
-------------------------------------------------------------------------------------------
一、Java异常的基础知识
异常是程序中的一些错误，但并不是所有的错误都是异常，并且错误有时候是可以避免的。比如说，你的代码少了一个分号，那么运行出来结果是提示是错误java.lang.Error；如果你用System.out.println(11/0)，那么你是因为你用0做了除数，会抛出java.lang.ArithmeticException的异常。
有些异常需要做处理，有些则不需要捕获处理，后面会详细讲到。 天有不测风云，人有旦夕祸福，Java的程序代码也如此。在编程过程中，首先应当尽可能去避免错误和异常发生，对于不可避免、不可预测的情况则在考虑异常发生时如何处理。 Java中的异常用对象来表示。Java对异常的处理是按异常分类处理的，不同异常有不同的分类，每种异常都对应一个类型（class），每个异常都对应一个异常（类的）对象。 异常类从哪里来？有两个来源，一是Java语言本身定义的一些基本异常类型，二是用户通过继承Exception类或者其子类自己定义的异常。Exception
类及其子类是 Throwable 的一种形式，它指出了合理的应用程序想要捕获的条件。 异常的对象从哪里来呢？有两个来源，一是Java运行时环境自动抛出系统生成的异常，而不管你是否愿意捕获和处理，它总要被抛出！比如除数为0的异常。二是程序员自己抛出的异常，这个异常可以是程序员自己定义的，也可以是Java语言中定义的，用throw 关键字抛出异常，这种异常常用来向调用者汇报异常的一些信息。 异常是针对方法来说的，抛出、声明抛出、捕获和处理异常都是在方法中进行的。 Java异常处理通过5个关键字try、catch、throw、throws、finally进行管理。基本过程是用try语句块包住要监视的语句，如果在try语句块内出现异常，则异常会被抛出，你的代码在catch语句块中可以捕获到这个异常并做处理；还有以部分系统生成的异常在Java运行时自动抛出。你也可以通过throws关键字在方法上声明该方法要抛出异常，然后在方法内部通过throw抛出异常对象。finally语句块会在方法执行return之前执行，一般结构如下：
try{
程序代码
}catch(异常类型1 异常的变量名1){
程序代码
}catch(异常类型2 异常的变量名2){
程序代码
}finally{
程序代码
} catch语句可以有多个，用来匹配多个异常，匹配上多个中一个后，执行catch语句块时候仅仅执行匹配上的异常。catch的类型是Java语言中定义的或者程序员自己定义的，表示代码抛出异常的类型，异常的变量名表示抛出异常的对象的引用，如果catch捕获并匹配上了该异常，那么就可以直接用这个异常变量名，此时该异常变量名指向所匹配的异常，并且在catch代码块中可以直接引用。这一点非常非常的特殊和重要！
Java异常处理的目的是提高程序的健壮性，你可以在catch和finally代码块中给程序一个修正机会，使得程序不因异常而终止或者流程发生以外的改变。同时，通过获取Java异常信息，也为程序的开发维护提供了方便，一般通过异常信息就很快就能找到出现异常的问题（代码）所在。 Java异常处理是Java语言的一大特色，也是个难点，掌握异常处理可以让写的代码更健壮和易于维护。
---------------------------------------------------------------------------------------》
在可能会出现exception的地方，要使用try－catch或者throws或者两者都要。我的判断依据是：如果对可能出现的exception不想被外部（方法的调用者）知道，就在方法内部try－catch掉这个exception；如果希望外部知道，则在catch到之后把exception直接抛出或者抛出自定义的exception。
一、异常的种类
java异常可以分成两大类：Exception和RuntimeException(虽然RuntimeException是从Exception继承的)。exception异常代表“无法避免的异常”
如io异常 往往这类异常是由于外部原因造成的，程序本身无法保证他们不发生，所以这类异常必须捕获。如果在函数内部无法处理这个异常必须再次抛出（在函数后面用throws语句），如果什么都不做就出现编译错误。
runtimexception是指“可以避免的异常”，如 null引用异常，这类异常都是由程序内部原因造成的，是可以避免的。对于这类异常可以忽略他们，但一旦发生程序就会异常终止。这类异常对debug非常有帮助，当然，如果需要也可以catch。
另外，有些地方即使不会有exception，但是从商业逻辑上是错误的、非预期的，也可以抛出user exception。例如，用户输入非法，bank account非法透支等等。
二、主要原则
处理意外的一个重要原则，就是要么处理，要么接着抛，决不能吃掉（You either handle it, or throw it. You don’t eat it.）这就是说，当你捕获一个异常之后，必须决定是否立即处理这个异常，或者继续抛出这个异常（或者另一个自定义异常），以便由调用的客户端捕获之。当客户端捕获到以后，又会继续进行类似的判断。
一般来说，GUI端是要处理异常的，比如JSP捕获到异常之后，需要先是给用户一个友好的出错信息，而不要给出系统的出错信息。系统的出错信息一方面不太友好，另一方面提供了太多的系统信息，容易被恶意用户用来攻击系统。
换句话说，所有的异常最终必须有一个终极的处理者，这就是GUI。至于中间的环节，比如在服务器端运行的JavaBean是否要处理捕获到的异常，还是继续抛出所捕获的异常，需要视具体情况处理。
除非你想把异常处理的责任交给调用者，一般不用throws。 比如你要读入一些文件，如果你想通知调用者，让调用者决定如何处理这个异常，你就把这个异常throws给调用者；如果你知道应该如何处理这个异常，或者你想把异常马上解决，你可以就地catch她。
这完全取决于你想把异常自己立即处理还是想把处理责任返回给调用者。取决于你的程序的结构和要求。
需要注意的有：
1、如果无法处理某个异常，那就不要捕获它。
2、如果捕获了一个异常，请不要胡乱处理它。
3、尽量在靠近异常被抛出的地方捕获异常。
4、在捕获异常的地方将它记录到日志中，除非您打算将它重新抛出。
5、按照您的异常处理必须多精细来构造您的方法。
6、需要用几种类型的异常就用几种，尤其是对于应用程序异常。
三、异常嵌套和捕获适当的异常
按照Java语言的定义，所谓异常（Exception）指的就是向调用方法（calling method）表示发生非正常情况的习惯方式。下面讨论两种在处理异常时可兹利用的技术：异常嵌套和捕获适当的异常。
异常嵌套
你在试图捕获异常并打算扔出异常时该采取什么措施呢？同时，你希望原始的异常信息可用吗？
要回答以上的问题你不妨尝试一下NestedException类。具体的编程并不难，唯一要做的无非是利用构造器并且重载printStackTrace()以便显示出正确的数据。
此外，你还应当考虑封装Throwable而非Exception类来创建更具有重用性的组件。之后，你可以创建NestedRuntimeException变量封装Throwable但无需对其进行声明。
捕获适当的异常
正确地处理异常并不是一项轻松的任务，这是因为异常的处理有时会导致程序出现其他不明行为。不过，以下三条规则可以帮助你避免错误处理异常所可能遭遇的风险。
规则 #1: 总是捕获扔出异常的类型而不要理睬异常的超类。 为了遵守通常的代码习惯，你可以采用Exception类的大写字母作为变量名，如下所示：
catch(FileNotFoundException fnfe)
以及
catch(SQLException sqle)
规则 # 2: 决不让catch块留空。在很多情况下虽然确实编写了try/catch块但在代码的catch部分却什么都没有做。或者，如果采用了日志API（Logging API），那么请编写代码把异常写到日志中。
规则 # 3: 决不扔出Exception基类的实例。开发人员应当总是扔出自己创建的异常类。
扔出异常的API很难处理。在声明方法扔出java.lang.Exception的情况下，所有的问题都会强加在API用户的头上，这样他们就无法以一种专业的编程方式来处理异常。通过为扔出API声明Exception类的子类这一举措，API开发人员就可以减轻用户的负担。
以上提到的两种技术在处理异常时还可能用得更好、更适当。嵌套技术令异常扔到另一异常的内部，而捕获适当的异常令程序调试大大简化。