异常(三)：使用throws声明抛出异常和使用throw抛出异常

2019独角兽企业重金招聘Python工程师标准>>>

1. 使用throws声明抛出异常：

使用throws声明抛出异常的思路是，当前方法不知道如何处理这种类型的异常，该异常应该由上一级调用者处理；如果main方法也不知道如何处理这种类型的异常，也可以使用throws声明抛出异常，该异常将交给JVM处理。JVM对异常的处理方法是：打印异常的跟踪栈信息，并终止程序运行，这就是前面程序在遇到异常后自动结束的原因。

throws声明抛出异常只能在方法签名中使用。如果某段代码中调用了一个带throws声明的方法，该方法声明抛出了Checked异常，则表明该方法希望它的调用者来处理该异常。也就是说，调用该方法时要么放在try块中显式捕获该异常，要么放在另一个带throws声明抛出的方法中。

使用throws声明抛出异常时有一个限制：子类方法声明抛出的异常类型应该是父类方法声明抛出的异常类型的子类或相同，子类方法声明抛出的异常不允许比父类方法声明抛出的异常多。

由此可见，使用Checked异常至少存在如下两大不便之处：

• 对于程序中的Checked异常，Java要求必须显式捕获并处理该异常，或者显式声明抛出该异常，这就增加了编程复杂度。
• 如果在方法中显式声明抛出Checked异常，将会导致方法签名与异常耦合，如果该方法是重写父类的方法，则该方法抛出的异常还会受到被重写方法所抛出异常的限制。

在大部分情况下，推荐使用Runtime异常，而不使用Checked异常。尤其当程序需要自行抛出异常时，使用Runtime异常将更加简洁。

当使用Runtime异常时，程序无需在方法中声明抛出Checked异常，一旦发生了自定义错误，程序只管抛出Runtime异常即可。

如果程序需要在合适的地方捕获异常并对异常进行处理，则一样可以使用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);
	}
}

 

 

转载于:https://my.oschina.net/u/2914561/blog/827721