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.统一开发过程》
《企业应用架构模式》
《敏捷软件开发原则-模式与实践》

转载于:https://www.cnblogs.com/lijma/p/10830047.html