[设计文档]系统异常设计
数 银 在 线
技术开发部文档
系统异常设计规范
版本 V1.0
Powered By
                                    王吉晨
                                    MSc certificated By British Computer Society
                                    Senior Java & Java RTS Developer
                                    Former NASA Scientist
系统异常设计规范
系统错误1简介
本文档介绍了系统异常设计的规范，所有数银在线的系统异常设计今后均按照本文制定的规范实施。异常分为系统级和业务级，系统级异常面向系统维护和开发人员，业务级的异常面向系统的使用者，即业务人员，一般要根据具体系统的业务规则去定义。本文对系统级的异常做了定义，对业务级的异常做了实现模型的设计。
1.1背景
当前所有数银系统中，对异常的定义及提示都是各成一套体系，对异常的捕捉及处理没有一个统一的规范。尤其是异常的命名，提示信息，抛出及处理的位置都非常混乱，导致系统程序在出错后的维护非常不便，难以快速定位至出错的根源。业务级的异常对系统使用者的提示也不够友好和专业。
1.2目标
建立异常的定义，处理，提示机制的规范，使异常的处理能够统一管理，异常的提示信息可以通过配置实现，而非写死在系统代码中。异常类型的判断均在系统的服务层进行，最终将结果返回给展现层，展现层通过事先配置好的异常代码和提示消息的映射关系来显示对应的提示消息。
1.3定义和术语
系统级异常：系统运行时的异常，如数据库连接失败，程序中的空指针异常，服务页面无法到等，通常无需系统使用者关注的问题，即因为程序出错而导致的问题。
业务级异常：和业务逻辑相关的异常，即用户的操作导致了某个业务流程无法进行，造成业务数据错误时发生的异常，和系统本身的运行没有关系。
1.4参考文档
无
2异常设计
异常分为系统级和业务级，本节将详细说明两种异常的定义，在系统程序中的实现，给出了异常抛出，捕获和处理的流程机制。
2.1系统级异常
系统级异常指的是系统程序本身出现的错误，产生的异常，这类异常按级别也可以分为三个等级，如表2-1所示，列出了各种系统级异常的定义。
系统异常级别
异常定义
异常实例
程序级
因程序代码编写错误而产生的，而此类异常一般在系统上线前的测试可以检查出来
空指针异常
框架级
系统程序代码调用一些第三方类库时出现的错误，比如框架本身的错误
线程数量耗尽
底层系统
操作系统相关的底层错误，一般是系统底层出现了错误，如网络中断，和程序本身无关。
Broken pipe，网络中断
表2-1 系统级异常定义
系统级的异常在我们现有系统的分层结构中，会在各个层中出现，如图2-1所示各层异常出现的位置。对系统级的异常，系统将提供一个统一的提示信息（如提示用户系统服务不可用），并将详细地记录出错的程序堆栈信息，供开发人员进行错误修复。
图2-1 各层的系统异常
以业务逻辑层为界，所有在业务逻辑层内和业务层之后所发生的系统异常，均抛至业务逻辑层进行处理（包括框架本身的异常），最终将结果传递给展现层进行错误消息的提示。
2.2业务级异常
业务级异常的定义和处理必须结合实际的业务规则进行定义，与系统程序本身以及底层系统无关，即在系统运行时，系统程序和底层程序没有出错，该错误是面向业务层面的，为业务出错。Java异常分为两大类:checked 异常和unChecked 异常。所有继承java.lang.Exception 的异常都属于checked异常。所有继承java.lang.RuntimeException的异常都属于unChecked异常。业务级的异常一般可以定义为unChecked异常，即在运行时抛出的，根据业务层执行的结果，对照业务规则来抛出业务的异常，然后通过一个统一的业务异常处理来检查该业务异常的类型，最终提示给用户面向业务的错误信息。图2-2描述了业务级异常定义，处理的模型。
图2-2 业务级异常模型
通过定义一个BusinessException集成RuntimeException来抽象所有的业务异常，让所有的业务层的服务接口中的方法，均都抛出业务异常，最终由调用该业务接口的类去捕获并处理该异常（展现层调用则提示错误消息，服务层调用则进行相关业务处理）。
举例说明，如在图中定义的用户不存在异常（UserNotExistException）可用于用户登录时，查对比用户信息，发现用户信息不正确则抛出该异常。在调用该服务的展现层中捕获该异常并根据该异常的名称返回提示信息。
2.3异常模型设计
Java异常处理通过五个关键字来实现，try,catch,throw ,throws, finally。具体的异常处理结构由try….catch….finally块来实现。try块存放可能出现异常的java语句，catch用来捕获发生的异常，并对异常进行处理。Finally块用来清除程序中未释放的资源。不管理try块的代码如何返回，finally块都总是被执行。Java给错误进行了统一的分类，通过扩展Exception类或其子类来实现。从而避免了相同的错误可能在不同的方法中具有不同的错误信息。在不同的方法中出现相同的错误时，只需要throw 相同的异常对象即可。通过异常类，可以给异常更为详细，对用户更为有用的错误信息。以便于用户进行跟踪和调试程序。把正确的返回结果与错
误信息分离。降低了程序的复杂度。调用者无需要对返回结果进行更多的了解。强制调用者进行异常处理，提高程序的质量。当一个方法声明需要抛出一个异常时，那么调用者必须使用try….catch块对异常进行处理。当然调用者也可以让异常继续往上一层抛出。
根据Java的这中特性，我们设计了一个异常抛出及处理的模型，如图2-3所示，今后所有系统开发中的异常设计均按照该模型的规范进行。总的原则是所有业务级的异常均使用RuntimeException，即所有业务接口均抛出该异常，所有系统级的异常在业务层中全部处理掉并重新封装为一个统一的业务异常（可提示系统错误，请联系开发人员），并将系统错误记录在后台日志，无需展现给系统使用者
3规范说明
如果一个异常是致命的，不可恢复的。或者调用者去捕获它没有任何益处，使用unChecked异常。如果一个异常是可以恢复的，可以被调用者正确处理的，使用checked异常。在使用unChecked异常时，必须在在方法声明中详细的说明该方法可能会抛出的unChekced异常。由调用者自己去决定是否捕获unChecked异常

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。