在学习Java的过程中,想必大家都一定学习过异常这个篇章,异常的基本特性和使用这里就不再多讲了。想必大家都能够理解看懂,并正确使用。
但是,光学会基本异常处理和使用不够的,在工作中出现异常并不可怕,有时候是需要使用异常来驱动业务的处理,例如: 在使用唯一约束的数据库的时候,如果插入一条重复的数据,那么可以通过捕获唯一约束异常DuplicateKeyException
来进行处理,这个时候,在server层中就可以向调用层抛出对应的状态,上层根据对应的状态再进行处理,所以有时候异常对业务来说,是一个驱动方式。
有的捕获异常之后会将异常进行输出,不知道细心的同学有没有注意到一点,输出的异常是什么东西呢?
下面来看一个常见的异常:
一个空指针异常:
大家有没有发现一个特点,就是异常的输出是中能够精确的输出异常出现的地点,还有后面一大堆的执行过程类调用,也都打印出来了,这些信息从哪儿来呢? 这些信息是从栈中获取的,在打印异常日志的时候,会从栈中去获取这些调用信息。能够精确的定位异常出现的异常当然是好,但是我们有时候考虑到程序的性能,以及一些需求时,我们有时候并不需要完全的打印这些信息,并且去方法调用栈中获取相应的信息,是有性能消耗的,对于一些性能要求高的程序,我们完全可以在这一个方面为程序性能做一个提升。
所以如何避免输出这些堆栈信息呢? 那么自定义异常就可以解决这个问题:
首先,自动异常需要继承RuntimeException, 然后,再通过是重写fillInStackTrace
, toString
方法, 例如,下面我定义一个AppException
异常:
那么为什么要重写fillInStackTrace
, 和 toString
方法呢? 我们首先来看源码是怎么一回事.
RuntimeException
是继承Exception
,但是它里面去只是调用了父类的方法,本身是没有做什么其余的操作。那么继续看Exception
里面是怎么回事呢?
从源码中可以看到, Exception
里面也是直接调用了父类的方法,和RuntimeException
一样,自己其实并没有做什么。 那么直接来看Throwable
里面是怎么一回事:
从源码中可以看到,到Throwable
就几乎到头了, 在fillInStackTrace()
方法是一个native
方法,这方法也就是会调用底层的C语言,返回一个Throwable
对象, toString
方法,返回的是throwable
的简短描述信息, 并且在getStackTrace
方法和 getOurStackTrace
中调用的都是native
方法getStackTraceElement
, 而这个方法是返回指定的栈元素信息,所以这个过程肯定是消耗性能的,那么我们自定义异常中的重写toString
方法和fillInStackTrace
方法就可以不从栈中去获取异常信息,直接输出,这样对系统和程序来说,相对就没有那么”重”, 是一个优化性能的非常好的办法。那么如果出现自定义异常那么是什么样的呢?请看下面吧:
那么在异常异常的时候,系统将会打印我们自定义的异常信息:
所以特别简洁,优化了系统程序性能,让程序不这么“重”, 所以对于性能要求特别要求的系统。赶紧自己的自定义异常吧!