1. 使用throws声明抛出异常：java
使用throws声明抛出异常的思路是，当前方法不知道如何处理这种类型的异常，该异常应该由上一级调用者处理；若是main方法也不知道如何处理这种类型的异常，也可使用throws声明抛出异常，该异常将交给JVM处理。JVM对异常的处理方法是：打印异常的跟踪栈信息，并终止程序运行，这就是前面程序在遇到异常后自动结束的缘由。程序员
throws声明抛出异常只能在方法签名中使用。若是某段代码中调用了一个带throws声明的方法，该方法声明抛出了Checked异常，则代表该方法但愿它的调用者来处理该异常。也就是说，调用该方法时要么放在try块中显式捕获该异常，要么放在另外一个带throws声明抛出的方法中。编程
使用throws声明抛出异常时有一个限制：子类方法声明抛出的异常类型应该是父类方法声明抛出的异常类型的子类或相同，子类方法声明抛出的异常不容许比父类方法声明抛出的异常多。安全
因而可知，使用Checked异常至少存在以下两大不便之处：spa
- 对于程序中的Checked异常，Java要求必须显式捕获并处理该异常，或者显式声明抛出该异常，这就增长了编程复杂度。
- 若是在方法中显式声明抛出Checked异常，将会致使方法签名与异常耦合，若是该方法是重写父类的方法，则该方法抛出的异常还会受到被重写方法所抛出异常的限制。
在大部分状况下，推荐使用Runtime异常，而不使用Checked异常。尤为当程序须要自行抛出异常时，使用Runtime异常将更加简洁。日志
当使用Runtime异常时，程序无需在方法中声明抛出Checked异常，一旦发生了自定义错误，程序只管抛出Runtime异常便可。code
若是程序须要在合适的地方捕获异常并对异常进行处理，则同样可使用try...catch块来捕获Runtime异常。对象
使用Runtime异常是比较省事的方式，使用这种方式既能够享受“正常代码和错误处理代码分离”，“保证程序具备较好的健壮性”的优点，又能够避免由于使用Checked异常带来的编程繁琐性。所以C#、Ruby、Python等语言没有所谓的Checked异常，全部的异常都是Runtime异常。继承
但Checked异常也有其优点：Checked异常能在编译时提醒程序员代码可能存在的问题，提醒程序员必须注意处理该异常或者声明该异常由该方法调用者来处理，从而能够避免程序员由于粗心而忘记处理该异常的错误。字符串
2. 使用throw抛出异常：
当程序出现错误时，系统会自动抛出异常；除此以外，Java也容许程序自行抛出异常，自行抛出异常使用throw语句来完成。
2.1 抛出异常：
不少时候，系统是否要抛出异常，可能须要根据应用的业务需求来决定，若是程序中的数据、执行与既定的业务需求不符，这就是一种异常。因为与业务需求不符而产生的异常，必须由程序员来决定抛出，系统没法抛出这种异常。
若是须要在程序中自行抛出异常，则应使用throw语句，throw语句能够单独使用，throw语句抛出的不是异常类，而是一个异常实例，并且每次只能抛出一个异常实例。当Java运行时接收到用户自行抛出的异常时，一样会停止当前的执行流，跳到该异常对应的catch块，由该catch块来处理该异常。也就是说，不论是系统自动抛出的异常，仍是程序员手动抛出的异常，Java运行时环境对异常的处理没有任何差异。
若是throw语句抛出的异常是Checked异常，则该throw语句要么处于try块里，显式捕获该异常，要么放在一个带throws声明抛出的方法中，即把该异常交给该方法的调用者处理；若是throw语句抛出的异常是Runtime异常，则该语句无须放在try块里，也无须放在带throws声明抛出的方法中，程序既能够显式使用try...catch来捕获并处理该异常，也能够彻底不理会该异常，把异常交给方法调用者处理。
自行抛出Runtime异常比自行抛出Checked异常的灵活性更好，一样，抛出Checked异常则可让编译器提醒程序员必须处理该异常。
2.2 自定义异常类：
在一般状况下，程序不多会自行抛出系统异常，由于异常的类名一般也包含了该异常的有用信息。因此在选择抛出异常时，应该选择合适的异常类，从而能够明确地描述该异常的状况。在这种状况下，应用程序经常须要抛出自定义异常。
用户自定义异常都应该继承Exception基类，若是但愿自定义Runtime异常，则应该继承RuntimeException基类。定义异常类时一般须要提供两个构造器：一个是无参数的构造器，另外一个是带一个字符串参数的构造器，这个字符串将做为该异常对象的描述信息(也就是异常对象的getMessage()方法的返回值)。
2.3 catch和throw同时使用：
前面介绍的异常处理方式有以下两种：
- 在出现异常的方法内捕获并处理异常，该方法的调用者将不能再次捕获该异常。
- 在方法签名中声明抛出该异常，将该异常彻底交给方法调用者处理。
在实际应用中每每须要更复杂的处理方式---当一个异常出现时，单靠某个方法没法彻底处理该异常，必须由几个方法协做才可彻底处理该异常。也就是说，在异常出现的当前方法中，程序只对异常进行部分处理，还有些处理须要在该方法的调用者中才能完成，因此应该再次抛出异常。让该方法的调用者也能捕获到异常。
为了实现这种经过多个方法协做处理同一个异常的情形，能够在catch块中结合throw语句来完成。这种catch和throw结合使用的状况在大型企业级应用中很是有用。企业级应用对异常的处理一般分红两个部分：
- 应用后台须要经过日志来记录异常发生的详细状况。
- 应用还须要根据异常向应用使用者传达某种提示。在这种状况下，全部异常都须要两个方法共同完成，也就是必须将catch和throw结合使用。
2.4 异常链：
对于真实的企业级应用而言，经常有严格的分层关系，层与层之间有很是清晰的划分，上层功能的实现严格依赖于下层的API，也不会跨层访问。
当业务逻辑层访问持久层出现SQLException异常时，程序不该该把底层的SQLException异常传到用户界面，有以下两个缘由：
- 对于正经常使用户而言，他们不想看到底层SQLException异常，SQLException异常对他们使用该系统没有任何帮助。
- 对于恶意用户而言，将SQLException异常暴露出来不安全。
将底层的原始异常直接传给用户是一种不负责任的表现。一般的作法是：程序先捕获原始异常，而后抛出一个新的业务异常，新的业务异常中包含了对用户的提示信息，这种处理方式被称为异常转译。
这种把捕获一个异常而后接着抛出另外一个异常，并把原始异常信息保存下来是一种典型的链式处理，也被称为“异常链”。
在JDK1.4之前，程序员必须本身编写代码来保持原始异常信息。从JDK1.4之后，全部Throwable的子类在构造器中均可以接收一个cause对象做为参数。这个cause就用来表示原始异常，这样能够把原始异常传递给新的异常，使得即便在当前位置建立并抛出了新的异常，你也能经过这个异常链追踪到异常最初发生的位置。
从JDK1.4以后，Throwable基类已有了一个能够接收Exception参数的方法：
public class SalException extends Exception{
public SalException(){
}
public SalException(String msg){
super(msg);
}
public SalException(Throwable t){
super(t);
}
}
