第六天、日志错误码异常设计实践

小源搬砖ing
972 阅读2分钟

1. 日志设计文档

日志记录规约：

  1. 应当天日志命名。以应用名换.log来保存。例如 user.log 代表是用户相关的日志
  2. 过往日志命名。以{logname}.log.{保存日期}命名，日期格式为:yyyy-MM-dd。
  3. 日志文件至少保存15天。便于排查某些以周为频次发生的异常。
  4. 敏感信息联机存储6个月。网络安全相关法律的规定。
  5. 日志信息包括：详细的错误信息，异常堆栈信息。
  6. 日志输出时，应该使用占位符的方式。比如：log.warn("张山退掉了{}到{}的车票", "北京", "上海")
  7. 禁止直接用JSON将对象直接转为String
  8. 尽量使用英文了描述日志信息。
  9. debug，info级别的日志配置打印打开进行控制打印，一般生产不需要这种日志，太多了。

image.png

2. 错误码设计

错误码规约：

  1. 定义时要有字母也要有数字
  2. 要分级分类管理
  3. 不能直接输出给用户作为提示信息使用
  4. 不要与业务架构或者组织架构挂钩
  5. 使用者避免随意定义新的错误码
  6. 便于不用语言的开发者之间协作 image.png

3. 异常处理

异常处理设计

  1. 使用全局的GlobalExceptionHandler进行错误的全局处理在全局异常处理里面有对异常进行封装成指定model返回的逻辑。model的属性信息查看第三点
  2. 错误转义统一使用：继承于untimeException的一个自定义异常进行往外抛出，抛出后由全局异常处理器进行统一处理
    例如，数据库发生异常，则：new BusinessException(errorCode, errorInfo) 进行抛出，由全局异常处理器封装成统一的返回对象进行返回
  3. 返回的model定义 
    HttpResultModel  
{  
    "data“:返回的model信息，  
    "errorCode", 错误编码,  
    "errorInfo":"错误信息",  
    "success":是否返回成功，正常返回用true，错误返回用false  
}
  4. 业务级别的异常，比如根据实际的业务进行捕获并且根据定义的错误码进行处理
avatar
文章
阅读
粉丝