Java 异常设计最佳实践

  • 时间:
  • 浏览:4
  • 来源:彩神大发pk10_神彩大发pk10官方

非检查异常,也称运行时异常RuntimeException ,继承自RuntimeException,所有非检查详细也有个特点,可是我代码我太久 都能否 补救它们的异常也能通过编译,全都 它们称作unchecked exception。RuntimeException 有你是什么也是继承自Exception



从顶端异常继承树都能否 看出,全都 异常都继承自Throwable,这也原因分析分析着着所有异常详细也有都能否 抛出的。

在讲Java异常实践然后,先理解一下什么是异常。到底什么才否有 异常呢?人太好 异常都能否 看做在大伙编程过程中遇到的你是什么意外清况 ,当出显什么意外清况 时大伙无法继续tcp连接正常的逻辑补救,此时大伙就都能否 抛出另一六个异常。

具体来说,广义的异常都能否 分为ErrorException两大类。

顶端提到,对于检查异常,强制要求开发者不都能否 进行补救,也可是我开发者要么对其进行try catch,要么往上层抛。不可能 检查异常全都 ,就原因分析分析着着tcp连接中不都能否 再加全都 的异常补救代码,原因分析分析着晦涩的异常补救,否则检查异常容易破坏接口法律法律依据。为了补救检查异常带来的不足英文,大伙都能否 利用异常转译的法律法律依据,将检查异常转化为非检查异常。

Error表示运行应用tcp连接中较严重问提。大多数错误与代码编写者执行的操作无关,而表示代码运行时 JVM(Java 虚拟机)出显的问提。类似于 ,Java虚拟机运行错误Virtual MachineError,当 JVM 不再有继续执行操作所需的内存资源时,将出显OutOfMemoryError,虚拟机错误还有StackOverflowError 、InternalError、 UnknownError等。什么异常所处时,Java虚拟机(JVM)一般会取舍tcp连接终止。突然见到的Error还有LinkageError(结合错误),具体有 NoSuchMethodError 、IllegalAccessError 、NoClassDefFoundError

前面的章节过,应用系统异常都能否 从用户和开发者另一六个视角去考虑。否则,大伙都能否 把异常划分为业务操作异常和系统内内外部运行时异常有你是什么类型。抛出业务级异常或系统运行时异常的决策,不都能否 与应用系统有你是什么的架构层次相结合,考虑所要补救异常的层次。如图所示为另一六个典型的异常层次底部形态:



其中,BussinessException 属于基本业务操作异常,所有业务操作异常都继承于该类。类似于 ,通常 UI 层或 Web 层是由系统最终用户执行业务操作驱动,否则最好抛出业务类异常。ServiceException 一般属于顶端服务层异常,该层操作引起的异常一般包装成基本 ServiceException。DAOException 属于数据访问相关的基本异常。

异常层次底部形态应该以有你是什么普遍通用的原则定义。为此,大伙都能否 利用面向对象语言具备多态的性质,隐藏异常的实际实现。对于异常 service 而言,只不都能否 捕获最基本的应用tcp连接异常 AppException,异常补救过滤器会自动过滤实际异常类型并找到相应的异常补救器。另外,在法律法律依据的 throws 一段话中勿需放上去大量的检查异常;对法律法律依据调用者可是我会出显混乱的 catch 块,最多不可能 只所处另一六个用于补救基本应用tcp连接异常 AppException(委托给异常 service 补救)。

在web编程中,一般对控制层的异常都应该做统一补救,不可能 控制层向顶端对用户,全都 大伙要在控制层捕获service所有不可能 出显的异常。顶端也提到大伙在控制层对每个service调用进行try catch显然会很繁琐否则也会原因分析分析着大量重复代码,全都 在遇到你是什么 清况 时大伙一定要考虑引入统一异常补救机制,而全都 框架也提供了然后的补救机制,如Spring的AOP,SpringMVC的 ExceptionHandler、RESTEasy的ExceptionMapper。

一般当tcp连接所处异常时,通常异常补救不可能 不都能否 做你是什么通用补救,如异常日志记录、异常通知,重定向到另一六个统一的错误页面(如 Web 应用)等。不可能 什么通用异常补救放置于 catch 块中,将原因分析分析着大量的重复代码,从而不可能 引起日志冗余、同一异常的实现繁复等问提。另外,大量异常补救tcp连接放置于 catch 块中造成tcp连接的高耦合性。为了补救此类问提,有必要分离出异常补救tcp连接、统一异常补救风格、降低耦合性、增强异常补救模块的复用程度。通常的异常补救模式包括业务委托模式(Business Delegate)、前端控制器模式(Front Controller)、拦截过滤器模式(Intercepting Filter)、AOP 模式、模板法律法律依据模式等。

而对于系统开发者而言,更多的是从系统内内外部逻辑来看异常。有一每项异常不都能否 内内外部截获补救即try catch,而另外一每项异常对于异常产生源而言无法进行有效补救,从而不都能否 向外抛出异常以待大慨的调用者进行补救。对于开发者而言,不都能否 预见异常,否则不都能否 考虑好久补救异常,好久抛出异常,必要时以有你是什么法律法律依据记录或通知异常。总而言之,开发者不都能否 通过对系统运行时不可能 出显的异常尽不可能 所补救以保证系统的正常运行,并对于无法补救的异常以有你是什么大慨的法律法律依据记录、通知、呈现以便找到所处异常的原因分析分析着,从而补救或补救异常。

不都能否 注意的是,大伙在对异常进行转译的然后一定要在构造法律法律依据中传入原异常的throwable对象,然后都能否 保留原异常栈信息,而详细也有把原异常用然后异常详细替换掉。

当然,大伙也都能否 根据实际清况 将另一六个非检查异常包装成另一六个检查异常。

编程错误原因分析分析着的异常 :在你是什么 类别里,异常的出显是不可能 代码的错误(譬如NullPointerException、IllegalArgumentException、IndexOutOfBoundsException )。代码通常对编程错误没法什么对策,全都 它一般是非检查异常。

资源错误原因分析分析着的异常 :当获取资源错误时引发的异常。类似于 ,系统内存不足英文,不可能 网络连接失败。客户端对于资源错误的反应是视清况 而定的。客户端不可能 一段时间然后重试不可能 仅仅记录失败否则将tcp连接挂起。

常见的检查异常有:

没法到底好久适合使用检查异常呢?有另一六个简单的原则是:

通常大伙所说的异常指的详细也有Exception的子类,它们具体都能否 分为两大类在Java,Exception的子类和RuntimeException的子类,它们分别对应着检查异常和非检查异常。

检查异常,继承自Exception类。对于检查异常,Java强制大伙不都能否 进行补救。对于抛出检查异常的API大伙有有你是什么补救法律法律依据:

ps:人太好 Error也是另一六个检查型的。

对于Spring MVC框架统一异常补救机制请参考:Spring MVC 中的异常补救 (handling exceptions)

对于Restful框架的统一异常补救机制请参考: RESTEasy中的通用异常补救ExceptionMapper

Java为异常设计了一套异常补救机制,当tcp连接运行过程中所处你是什么异常清况 时,tcp连接我太久 返回任何值,可是我抛出封装了错误信息的异常对象,Java 语言提供了专门的异常补救机制去补救什么异常。

否则Java缘何又设计了检查异常呢,人太好 自己人太好 检查异常的所处还是有必要的。检查异常都能否 使API的调用者明确知道API不可能 抛出的异常信息并让大伙也能对你是什么 异常清况 做补救。不可能 是说,检查异常允许调用者从异常中恢复,而非检查异常一般是编程错误,调用者无法对其进行补救。 否则使用检查异常不都能否 谨慎。不可能 检查异常会强制调用者对其进行try catch不可能 往上层抛,然后就给调用者造成了何必 要的负担。

人太好 对于检查异常所处的必要性突然都很有争议,Java是第另一六个使用检查异常的主流面向对象语言,而C++和C#详细也有没法检查异常的。全都 大伙在编程中详细使用非检查异常(RuntimeException的子类)也是都能否 的。

对于多层系统,每一层详细也有该层的基本异常。在层与层之间的信息传递与法律法律依据调用然后,一旦在某层所处异常,传递到上一层的然后,一般包装成该层异常,直至与用户最接近的 UI 层,从而转化成用户友好的错误信息。

getAllAccounts()抛出了另一六个checked exception。你是什么 法律法律依据的调用者就不都能否 补救这另一六个异常,尽管它也告诉我在getAllAccounts()中什么文件找不都能否 以及什么数据库一段话失败,也告诉我该提供什么文件系统不可能 数据库的事务层逻辑。然后,异常补救就在法律法律依据调用者和法律法律依据之间形成了另一六个不恰当的紧耦合。否则不可能 大伙真正遇到你是什么 清况 ,大伙详细都能否 没法做:

异常转译可是我将有你是什么异常转换为另有你是什么异常。异常转译针对所有继承 Throwable 超类的异常类而言的。对于大伙开发者来说,不可能 遇到检查异常,而大伙又告诉我该对其做出怎么能否补救,没法大伙详细都能否 在catch块里将其封装成另一六个非检查异常否则抛出。类似于 下面你是什么 例子:

广义的讲,抛出异常分有你是什么不同的清况 :

全都 ,对于Error大伙编程中基本是用不都能否 的,也却一段话大伙在编程中都能否 忽略Error错误。全都 大伙通常所说的异常只的是Exception,而Exception可分为检查异常和非检查异常。

常见的非检查异常有:

没法缘何编程语言要设计异常呢?首先,引入异常然后,大伙就都能否 把错误代码从正常代码中分离出来进行单独补救,然后使代码变得更加整洁;其次,当出显你是什么特殊清况 时,大伙还都能否 抛出另一六个检查异常,告知调用者让其补救。

客户端的错误原因分析分析着的异常 :客户端代码试图违背制定的规则,调用API不支持的资源。不可能 在异常中显示有效信息一段话,客户端都能否 采取你是什么的补救法律法律依据。类似于 :解析另一六个格式不正确的XML文档也有抛出异常,异常中所含晒 效的信息。客户端都能否 利用你是什么 有效信息来采取恢复的步骤。

从系统最终用户的层厚来看,系统对于用户来说可是我另一六个黑盒,用户并告诉我系统怎么能否实现及运行,对用户而言,系统所出显的任何异常或错误,都属于系统运行时异常。全都 在设计面向最终用户服务的API时,应该捕获API所有不可能 出显的异常,并把异常清况 封装成与用户业务相近的提示信息,用户都能否 根据什么提示信息作出你是什么补救。