JAVA SpringBoot 设计应用程序异常体系思路

设计应用程序异常体系

在系统设计初期考虑应用程序的潜在问题是十分必要的，有效利用异常的特色，能够知足应用的正确性或者健壮性等非功能性需求。

1. 异常设计方法

. 在架构设计中规定让错误处理更偏向于健壮性仍是正确性 . 肯定应用程序的安全区域边界 . 在架构设计中规定一组特定的异常处理技术 . 对穿越安全区域边界的数据进行合法性校验，并当数据非法的时候作出敏锐的反应 . 用断言来讲明编程假定，其中包括了前条件和后条件 . 规定合适的错误处理规模

2. 安全边界

图像界面，命令行界面，实时数据采集，外部文件，其余外部对象(假定此处的数据是肮脏且不可信的) ----- 数据验证类(这些类负债清理数据，它们构成了安全边界) ---- 内部类1-你（这些类能够假定数据都是干净且可信的） 让软件的某些部分处理 ”不干净的“数据，而让另一部分处理”干净的“数据，便可让大部分代码无须再负担错误检查数据的职责 安全边界的使用使断言和错误处理有了清晰的区分，安全边界的外部程序使用错误处理技术，安全边界内部创建断言技术，传进来的数据应该在安全边界的时候已经被清理过了。

3. 异常处理技术

. 尽量去处理异常,recommended . 声明异常，把异常传给方法的调用者 . 记录异常和相关信息 log . 使用默认值或替换数据 (限于数据不敏感系统) use default . 异常转译 exception translation . 忽略问题 ignore . 重试 retry . 恢复,enable again . rollback . shutdown system

4. 合法性校验

检查全部来源于外部的数据的值，网络，文件，用户，外部接口等。 . 数值，确保接受范围之类 . 字符串：确保长度 . ID: 确保验证合乎用途 . 溢出数据，注入的SQL命令，注入的HTML代码，以及传递给系统调用的数据 . 检查有害输入数据代码，缓冲区溢出，SQL注入，HTML注入，整数溢出，其余恶性输入数据 . 出错消息中是否避免出校攻击者攻入系统所需的消息(日志脱敏)。

5. 断言的应用

断言对于大型的复杂性程序或者可靠性要求极高的程序来讲尤为有用 用错误处理代码来处理预期会发生的状况，用断言来处理毫不应该发生的情况， 不该该使用断言来测试琐细问题，或可轻易修改的错误状况 不该使用断言来检查public方法的输入参数 能够用断言表达内部不定式，控制流不定式，初始条件，锁状态条件，结束条件，类不定式 若是发生异常状况触发了断言，那么要采起的措施不只仅是对错误作出恰当的反应了，而是应该修改程序的源代码并从新编译，而后发布软件的新版本。 用断言来注解 precondition和postconditions, 是契约设计的一部分。 precondition assertion: 调用代码要承担的责任 postcondition assertion: 被调用方要承担的责任

6. 可维护性设计原理（ 关键 业务的异常控制梳理流程）

面向对象+有效异常处理 = 可维护性设计 开始时候定义系统关键（！important）业务流程的行为模型，可定义一个用例模型 识别业务操做或用例(UML) -> 完善业务操做，定义粒度更小的行为(活动图) -> 识别关键故障场景或操做风险 -> 肯定操做或方法中的潜在故障点 -> 肯定故障点的处理策略 识别关键故障场景或操做风险：操做，风险，评估级别 肯定操做或方法中的潜在故障点： 利用OO流程分解方法+顺序图 肯定故障点的处理策略 评估代码，组件，API或架构风险和弱点的过程称为故障模式分析。 并入软件设计，都要深刻了解与语言特性和API相关的风险。 注意：该技术只使用与程序中的主要问题，旨在识别全局影响的关键风险区域，否者会陷入设计锁和流程当中。

7. Application 错误日志的跟踪和记录

Log Spec AC . Choose MDC or NDC . add a filter to inject fileds(x-trace-id) to MDC . resttemplate inject fileds(x-trace-id, vin,...) . json format . log pattern ToKnow https://opentracing.io/ focus on trace project http://reactivex.io/ mutiple thread

. 话题讨论

是否使用异常

产生异常和未产生异常的性能的较大差异，这就是说，应该遵循最佳编程实践，没必要再有效代码和性能间折中，解决异常的基本规则是成立的，在处理产生异常的代码时，原来的优先级保持不变。 把代码放在try-catch块反而阻止了JVM实现原本要执行的某些特定的优化 尽可能避免抛出异常 若是条件容许就处理异常 若是条件不容许就声明异常

受查异常与非受查异常

服务可能会发生异常，但愿调用者进行处理，就要抛出受查异常，受查异经常使用于控制业务逻辑 偶然异常，不是必然发生，也不须要调用者显示的经过异常来判断业务流程操做什么的，就可使用非受查异常了 避免没必要要的使用被检查异常，虽然检查异常大大提升了可靠性，然而过度的使用被检查的异常会使API用起来很是不方便，把被受查异常转变为非受查异常的一种技术是分红两个方法，一个返回boolean,表面是否调用

异常的传播

不用能异常来推卸责任，若是某种的错误状况能够在局部处理，那就应该在局部处理它，不要把原来能够在局部处理掉的错误当成一个未被捕获的异常抛出去。 避免在构造函数和析构函数里抛出异常，否则异常处理的规则立刻就会变得复杂。 高层的实现应该捕获低层的异常，同时抛出一个按照高层抽象进行解释的异常，这种作法被称为异常转译(exception translation) 避免使用一个空的catch块，忽略异常

异常日志的记录

对与不是特别重要的异常，不容许记录日志后又抛出异常，由于这样会屡次记录日志，只容许记录一次，低层日志记录错误参数，和结果，由系统高层异常处理器来记录异常栈。

关于健壮性和正确性的讨论

健壮性：不断尝试采起某些措施，以保证软件能够持续的运做下去，哪怕有时作出一些不够准确的结果。 正确性：永远不返回不许确的结果，不返回结果也比返回不正确的好

. 参考书籍：

《Robust Java中文版-Java异常处理、测试与调试》 《代码大全2》 《Effective Java, 2nd Edition》 《agile java》 《重构，改善既有代码的设计》 《测试驱动开发》 《Java编程思想第四版》 《rationa.统一开发过程》 《企业应用架构模式》 《敏捷软件开发原则-模式与实践》