列举网站建设的SEO策略,容桂佛山做app网站,地产网,安平网站建设培训异常简介
先上个图#xff0c;看一下常见的几个异常类型。 所有的异常都来自于Throwable。Throwable有两个子类#xff0c;Error和Exception。
Error通常表示的是严重错误#xff0c;这些错误是不建议被catch的。 注意这里有一个例外#xff0c;比如ThreadDeath也是继承自…异常简介
先上个图看一下常见的几个异常类型。 所有的异常都来自于Throwable。Throwable有两个子类Error和Exception。
Error通常表示的是严重错误这些错误是不建议被catch的。 注意这里有一个例外比如ThreadDeath也是继承自Error但是它表示的是线程的死亡虽然不是严重的异常但是因为应用程序通常不会对这种异常进行catch所以也归类到Error中。 Exception表示的是应用程序希望catch住的异常。
在Exception中有一个很特别的异常叫做RuntimeException。RuntimeException叫做运行时异常是不需要被显示catch住的所以也叫做unchecked Exception。而其他非RuntimeException的Exception则需要显示try catch,所以也叫做checked Exception。
不要忽略checked exceptions
我们知道checked exceptions是一定要被捕获的异常我们在捕获异常之后通常有两种处理方式。
第一种就是按照业务逻辑处理异常第二种就是本身并不处理异常但是将异常再次抛出由上层代码来处理。
如果捕获了但是不处理那么就是忽略checked exceptions。
接下来我们来考虑一下java中线程的中断异常。
java中有三个非常相似的方法interruptinterrupted和isInterrupted。
isInterrupted()只会判断是否被中断而不会清除中断状态。
interrupted()是一个类方法调用isInterrupted(true)判断的是当前线程是否被中断。并且会清除中断状态。
前面两个是判断是否中断的方法而interrupt就是真正触发中断的方法。
它的工作要点有下面4点
如果当前线程实例在调用Object类的waitwaitlong或waitlongint方法或joinjoinlongjoinlongint方法或者在该实例中调用了Thread.sleeplong或Thread.sleeplongint方法并且正在阻塞状态中时则其中断状态将被清除并将收到InterruptedException。如果此线程在InterruptibleChannel上的I / O操作中处于被阻塞状态则该channel将被关闭该线程的中断状态将被设置为true并且该线程将收到java.nio.channels.ClosedByInterruptException异常。如果此线程在java.nio.channels.Selector中处于被被阻塞状态则将设置该线程的中断状态为true并且它将立即从select操作中返回。如果上面的情况都不成立则设置中断状态为true。
看下面的例子 public void wrongInterrupted(){try{Thread.sleep(1000);} catch (InterruptedException e) {e.printStackTrace();}}
上面代码中我们捕获了一个InterruptedException但是我们仅仅是打印出了异常信息并没有做任何操作。这样程序的表现和没有发送一异常一样很明显是有问题的。
根据上面的介绍我们知道interrupted()方法会清除中断状态所以如果我们自身处理不了异常的情况下需要重新调用Thread.currentThread().interrupt()重新抛出中断由上层代码负责处理如下所示。 public void correctInterrupted(){try{Thread.sleep(1000);} catch (InterruptedException e) {Thread.currentThread().interrupt();}}
不要在异常中暴露敏感信息
遇到异常的时候通常我们需要进行一定程度的日志输出从而来定位异常。但是我们在做日志输出的时候一定要注意不要暴露敏感信息。
下表可以看到异常信息可能会暴露的敏感信息 除了敏感信息之外我们还要做好日志信息的安全保护。
在处理捕获的异常时需要恢复对象的初始状态
如果我们在处理异常的时候修改了对象中某些字段的状态在捕获异常的时候需要怎么处理呢 private int age30;public void wrongRestore(){try{age20;throw new IllegalStateException(custom exception!);}catch (IllegalStateException e){System.out.println(we do nothing);}}
上面的例子中我们将age重置为20然后抛出了异常。虽然抛出了异常但是我们并没有重置age最后导致age最终被修改了。
整个restore的逻辑没有处理完毕但是我们部分修改了对象的数据这是很危险的。
实际上我们需要一个重置 public void rightRestore(){try{age20;throw new IllegalStateException(custom exception!);}catch (IllegalStateException e){System.out.println(we do nothing);age30;}}
不要手动完成finally block
我们在使用try-finally和try-catch-finally语句时一定不要在finally block中使用return, break, continue或者throw语句。
为什么呢
根据Java Language SpecificationJLS的说明finally block一定会被执行不管try语句中是否抛出异常。
在try-finally和try-catch-finally语句中如果try语句中抛出了异常R然后finally block被执行这时候有两种情况
如果finally block正常执行那么try语句被终止的原因是异常R。如果在finally block中抛出了异常S那么try语句被终止的原因将会变成S。
我们举个例子
public class FinallyUsage {public boolean wrongFinally(){try{throw new IllegalStateException(my exception!);}finally {System.out.println(Code comes to here!);return true;}}public boolean rightFinally(){try{throw new IllegalStateException(my exception!);}finally {System.out.println(Code comes to here!);}}public static void main(String[] args) {FinallyUsage finallyUsagenew FinallyUsage();finallyUsage.wrongFinally();finallyUsage.rightFinally();}
}
上面的例子中我们定义了两个方法一个方法中我们在finally中直接return,另一方法中我们让finally正常执行完毕。
最终我们可以看到wrongFinally将异常隐藏了而rightFinally保留了try的异常。
同样的如果我们在finally block中抛出了异常我们一定要记得对其进行捕获否则将会隐藏try block中的异常信息。
不要捕获NullPointerException和它的父类异常
通常来说NullPointerException表示程序代码有逻辑错误是需要程序员来进行代码逻辑修改从而进行修复的。
比如说加上一个null check。
不捕获NullPointerException的原因有三个。
使用null check的开销要远远小于异常捕获的开销。如果在try block中有多个可能抛出NullPointerException的语句我们很难定位到具体的错误语句。最后如果发生了NullPointerException程序基本上不可能正常运行或者恢复所以我们需要提前进行null check的判断。
同样的程序也不要对NullPointerException的父类RuntimeException, Exception, or Throwable进行捕捉。
不要throw RuntimeException, Exception, or Throwable
我们抛出异常主要是为了能够找到准确的处理异常的方法如果直接抛出RuntimeException, Exception, 或者 Throwable就会导致程序无法准确处理特定的异常。
通常来说我们需要自定义RuntimeException, Exception, 或者 Throwable的子类通过具体的子类来区分具体的异常类型。
不要抛出未声明的checked Exception
一般来说checked Exception是需要显示catch住或者在调用方法上使用throws做申明的。
但是我们可以通过某些手段来绕过这种限制从而在使用checked Exception的时候不需要遵守上述规则。
当然这样做是需要避免的。我们看一个例子 private static Throwable throwable;private ThrowException() throws Throwable {throw throwable;}public static synchronized void undeclaredThrow(Throwable throwable) {ThrowException.throwable throwable;try {ThrowException.class.newInstance();} catch (InstantiationException e) {} catch (IllegalAccessException e) {} finally {ThrowException.throwable null;}}
上面的例子中我们定义了一个ThrowException的private构造函数这个构造函数会throw一个throwable,这个throwable是从方法传入的。
在undeclaredThrow方法中我们调用了ThrowException.class.newInstance()实例化一个ThrowException实例因为需要调用构造函数所以会抛出传入的throwable。
因为Exception是throwable的子类如果我们在调用的时候传入一个checked Exception很明显我们的代码并没有对其进行捕获 public static void main(String[] args) {ThrowException.undeclaredThrow(new Exception(Any checked exception));}
怎么解决这个问题呢换个思路我们可以使用Constructor.newInstance()来替代class.newInstance()。
try {Constructor constructor ThrowException.class.getConstructor(new Class?[0]);constructor.newInstance();} catch (InstantiationException e) {} catch (InvocationTargetException e) {System.out.println(catch exception!);} catch (NoSuchMethodException e) {} catch (IllegalAccessException e) {} finally {ThrowException.throwable null;}
上面的例子我们使用Constructor的newInstance方法来创建对象的实例。和class.newInstance不同的是这个方法会抛出InvocationTargetException异常并且把所有的异常都封装进去。
所以这次我们获得了一个checked Exception。 原文链接 本文为阿里云原创内容未经允许不得转载。
