1. JAVA异常体系
java异常机制是Java语言特性中很厉害也很重要的一种处理机制。
1. 异常的描述
- 异常应当描述导致当前异常发生的原因
- 根据异常栈快速定位到异常发生的位置
- 结合异常描述和异常栈解决异常
2. Java异常处理流程
以下为try...catch...finally的处理流程
3. Java的异常处理机制
4. Java的异常体系
2. 异常处理设计与实践
1. 异常抛出与捕获原则
- 非必要不使用异常
- 使用描述性消息抛出异常
- 力所能及的异常一定要处理
- 异常忽略要有理有据
2. JAVA异常体系捕获
目前基本上都是使用try...catch...finally体系来进行异常的捕获,但是在JDK7以后对资源的关闭有了一个新姿势tr with resource来对需要关闭资源的流进行捕获。3. NPE场景及其对应的处理对策
NPE:NullPointException- 使用JDK8的Optional优雅的防止NPE
- 实例化Optional
Optional.ofNullable(obj) - 使用orElse()方法解决NPE问题。该方法的作用是设置默认值,当发生NPE时,返回指定的默认值
- 使用ifPresent()方法解决NPE问题。
- 对象非空判断性能高 当循环总数<10000时,使用Optional与普通的嵌套null非空检测的查询都稳定在30ms。但是当总数循环>10000&<10000000时,Optional比普通嵌套null飞控检测查询性能提升了10-20倍,Option消耗时间稳定在35-65ms之间。当循环总数>10000000时,性能呈指数上升。
- 实例化Optional
- 使用JDK8的Optional优雅的防止NPE
3. 日志规约
1. 日志的功能
- 监控告警
- 记录行为轨迹
- 快速定位问题
2. 日志失效规约
- 当天日志命名。以
应用名换.log来保存。 - 过往日志命名。以
{logname}.log.{保存日期}命名,日期格式为:yyyy-MM-dd。 - 日志文件至少保存15天。便于排查某些以周为频次发生的异常。
- 敏感信息联机存储6个月。网络安全相关法律的规定。
3. 日志记录规约
- 系统应使用日志框架(SLF4J,JCL)的API而不时具体日志库中的。
- 在日志输出时,字符串变量之间的拼接应该使用占位符的方式。使用+会导致性能的消耗。
- 日志打印时禁止使用JSON工具直接将对象转为String。
- 尽量用英文来描述日志错误信息。
4. 日志输出规约
- 日志级别开关判断。对于
trace/debug/info级别的日志输出,必须进行日志级别的开关判断。 - 异常日志信息要完成。应该包括:案发现场信息,异常堆栈信息。
- 避免重复打印日志。重复打印日志,浪费磁盘空间,务必在日志配置中设置
additivity=false。
5. 扩展日志的设计与规约
- 扩展日志单独存储。比如:打点,临时监控,访问日志等。
- 错误日志单独存储。业务日志与错误日志分开存储。
4. 错误码规约
1. 规约
- 定义时要有字母也要有数字
- 要分级分类管理
- 不能直接输出给用户作为提示信息使用
- 不要与业务架构或者组织架构挂钩
- 使用者避免随意定义新的错误码
- 便于不用语言的开发者之间协作
- 例如Http错误吗。403:网站访问错误提示。401:一般为登录信息错误。404:找不到资源等等
2. 示例
5. 异常与日志综合实践
1. 在Controller统一捕获异常
2. 使用全局异常处理组件:GlobalExceptionHandler
3. API层异常设计实践
- 严格约束条件判断。API层需要保证进入的数据时合法的合规的。包括基本判断约束+实体属性约束。
- 客户端返回要有好。API层要给客户端返回状态码及其对应的错误消息。
- 下层异常转义。将Service层、Manager层异常转译为API层异常。
- 错误码文档要规范。系统状态码对应的异常或错误细腻些以及可能发生异常的原因,要整理成方便用户查阅的文档,同步给接口调用方。
4. Service层异常设计实践
- 严格约束条件。基本判断约束+实体约束条件+业务条件约束(根据业务来)。
- 抛出指定类型的异常。Service层抛出带有状态码或者指定类型的异常。
- 转移DAO层异常。将DAO层的异常转译为Service层或者更高层能够理解的异常。
5. DAO数据处理层异常实践
- 通用的DaoException并向上抛出。
- 框架层面有选择性的记录数据操作。
6. 怎么用有限的异常类处理业务中复杂多变的无限可能
- 定义通用的ServiceException。
- 结合多变的ErrorCode来对业务的各种情况进行定义。
7. 通过合理的设计降低系统的维护难度
-
通用模块单独拆分
-
合理的领域划分
-
合适的工程结构