道路千万条,安全第一条
日志不规范,排查两行泪
java关于异常处理的相关流程
道路千万条,安全第一条
日志不规范,排查两行泪
java关于异常处理的相关流程
我们的异常处理流程过程, 总的来说分为生成异常、捕获异常、抛出异常 throw、生成异常throws。
枝繁叶茂的java异常体现,
异常抛出与捕获的原则:
- 非不要不适用异常
- 使用描述性消息抛出异常
- 力所能及的异常一定要处理
- 异常忽略要有理有据
try-catch-finally 流程的分析。
强制规约: 不能在finally块中使用return , 会覆盖正常流程的return。
以我们常见的I/O处理的 try-catch举例来说, 我们定义了IO流的打开, 需要在代码中显示的调用IO流的关闭。
但是在jdk1.7的时候, 我们可以用 try with resource进行代码编写, 就可以节省显示的调用IO流的关闭。
如下:
try(FileInputStream fis… ){
fis.read
}catch(Exception e){
}
但是在try()的语句块内, 不要用 new FileInputStream(new InputStream(xxx)) 这种模式, 这种也会出现无法关闭的情况。
如下图:
对于空指针异常来说, 我们经常需要在一个对象使用之前, 都要判断它是否为空,我们是否可以使得我们的代码更优雅呢?我们可以使用Optional优雅的防止NPE(空指针异常):
如下:
代码例子:
异常场景: 不要在foreach循环中, 进行remove、add节点操作。 而且, 循环中异常, 看情况是进行提前终止回滚, 或者当发生异常时, 先记录到某一处,进行标注, 由后续流程继续处理该异常。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-dGmEDgH2-1635675263206)(Day4 异常处理及日志规约.assets/image-20211030213609234.png)]
以下记录日志规约
日志的功能:
- 监控告警: 健康检查、指标监控
- 记录行为轨迹:查询指标监控、链路追踪
- 快速定位问题:
日志时效:
当天日志命名以 “应用名.log"来保存
过往日志命名:以“logname.log.yyyy-mm-dd”命名
日志至少保存15天
敏感操作信息联机存储6个月, 并且应记尽记, 便于排查问题及责任定位。
日志输出:
-
日志级别开关判断
- 对于trace/debug/info级别的日志输出, 必须进行日志级别的开关判断
-
异常日志信息要完整
- 案发现场信息
- 异常堆栈信息
-
避免重复打印日志
- 占磁盘空间, additivity=false
日志记录:
扩展日志规约:
- 扩展日志单独存储:打点,临时监控, 访问日志等单独存储
- 错误日志单独存储:业务日志与错误日志分开存储
日志规约:
- 在记录日志的框架上, 应使用slf4j 的api而不是具体日志库中的。
如果不是使用slf4j的话, 可以通过日志库适配器迁移
jul-to-slf4j
log4j-over-slf4j
jcl-over-slf4j
- 在日志输出时,字符串拼接使用占位符
- 日志打印禁止使用用JSON工具将对象转换成String
- 尽量用英文来描述日志错误信息(?? 防止中文乱码??,仁者见仁智者见智吧。强制U8的, 会出问题?)
错误码规约:
-
错误码的功用
-
系统间沟通便于处理
-
人与人沟通
-
人鱼系统间的沟通
总的来说, 就是让我们更方便的进行程序的逻辑处理与错误分析。
-
-
错误码规约
- 定义时要有字母也要有数字
- 要分级分类管理
- 不能直接处处给用户座位提示信息使用
- 不要跟业务架构或者组织架构挂钩
- 使用者不要随意定义新的错误码
- 便于不同语言的开发者之间协作
例子:
异常处理与日志综合实践
-
在controller层统一捕获异常
-
全局异常处理组件的定义与使用
-
API层异常设计实践
-
Service层异常设计实践
-
DAO数据处理层异常日志实践
- 使用DMC实现轻量级调用链路追踪
- 用有限的异常类处理业务中复杂多变的无限可能