内容简介:上次说了日志,不知道老铁遇见过没有,日志打印了一大堆,真的去找导致异常和错误的一条没有。出现这个问题的根本原因是什么?就是因为系统没有一个规范的统一的异常规范。有的老铁发现异常后,直接e.printStackTrace() 打印出来堆栈就结束了,其实这样是很危险的。如果前期对异常没有统一的处理,后期在进行统一和调整真心非常非常的困难,异常跟我们的业务逻辑耦合的非常深的。调整统一过来非常非常的难。所以在设计系统的刚开始就必须设计的完善。如果对刚开始的系统异常和业务异常没有规范化,就算后期分布式进行监控的时候也
上次说了日志,不知道老铁遇见过没有,日志打印了一大堆,真的去找导致异常和错误的一条没有。出现这个问题的根本原因是什么?就是因为系统没有一个规范的统一的异常规范。有的老铁发现异常后,直接e.printStackTrace() 打印出来堆栈就结束了,其实这样是很危险的。如果前期对异常没有统一的处理,后期在进行统一和调整真心非常非常的困难,异常跟我们的业务逻辑耦合的非常深的。调整统一过来非常非常的难。所以在设计系统的刚开始就必须设计的完善。如果对刚开始的系统异常和业务异常没有规范化,就算后期分布式进行监控的时候也是很困难的,监控系统无法知道是系统异常还是业务异常。无法准确的通知开发人员和运维人员。报警都不知道怎么报警,例如:一个密码输出错误的可能就引发报警,这样的结果是什么?报警量特别特别的大。如果不报警,到时候真出问题了,就玩完了。是不是 进退两难,说也不是,不说也不是。
场景回顾
-
老铁你遇到过不?
>是不是总结的很经典。反正都不是我的锅,大家都是成年人了。
出现异常我们该怎么办
其实反映了问题,如果用户存在问题,只要提示明确,用户都不会反映到电话客服那里。如果还需要用户来反馈,说明系统异常设计的都不合理,我们监控系统没有做到位,用户都知道这个问题了,我们系统还不知道。监控系统需要做到的就是在用户反馈之前先知道。如果异常定义的很棒很坚挺的话,看到提示都知道问题出在哪里了!目前很多系统要定位一个问题需要花很长的时间。才能定位到哪里出的问题。现在咱们就搞明白,到底哪里发生了问题,达到一个目标,快速的响应,快速的知道,对应的问题,定位到问题的根本原因,对方传错了,有明确的指示。不应该把他带到线上,带上生产环境下,应该在上线之前就应该抹杀掉。
系统异常设计的出发点
- 良好的异常信息提示,开发运维人员能快速定位
- 响应外部调用异常时,应能明确指明是内部异常还是调用条件不满足导至。
- 响应用户操作异常时,能友好的提示用户。
异常分类
内部异常
响应没办法按照用户期待的结果返回。
* 资源环境导致(系统环境异常、数据库连接超时、第三方服务响应超时)
* 第三方服务错误响应
已经调入到第三方系统上去了,第三方的系统本身软件有bug,导致的
* 第三方响应结果错误
按照约定返回1和0,结果返回了-1。
- 外部传入参数非法
>别人调用自身的系统,明确的告诉它参数传递错误。 - 错误的编码逻辑
>调用参数,本来传递1-10,结果你传递了11。 - 错误的配置
> 上线代码链接的是测试数据库 - 异常的业务数据(业务数据缺失)
>代码传递错误,custId 和 userId写反了。
业务异常
用户操作错误导致的,比如:密码错误。
* 用户操作错误
捕获异常。
* 业务条件不满足
业务的时候提前规范。
###系统中正确的捕获这类异常,并抛出
####1.方法入参进行合法性验证
* 对系统外部提供的接口(调用后立马验证,不要走了一段逻辑在进行验证),是必须要进行参数验证(必须)
* 系统内部对外外层提供接口,进行验证
* 工具类进行参数验证
* public 方法要进行验证
* private 方法(不建议参数验证)
2.第三方响应结果合法性验证
- 获取第三方法结果后,根据你们的约定进行验证
3.业务处理前,对业务业务前置条件进行验证
- 业务处理前,验证业务条件(验证佘额、验证这个帐户有没有被公安门锁定)
- 要考虑性能成本(验证身份证号码是不是存在的)
4.业务处理后,对处理结果进行验证
- 验证对方帐户是不是到帐了,转出帐户是不是成功扣款
5.对于可能会出现异常的代码进行 try catch 捕获
- 尝试恢复处理
- 直接抛出
- 转换后抛出
###系统出口统一拦截处理
统一拦截的目的是确定出去的异常是可控的,调用方能够明白异常的信息,这里出口是指系统对外统一响应逻辑,一般我们可分三类场景。
####1. Web Response
h5,pc页面
* 内部异常
引导至异常提示页
* 业务异常
返回对应提示消息至前端
* 未知异常
尝试进行识别,如果识别不了,转换成异常编码
####2. Http API接口响应
* 内部异常
返回接口不可用消息
- 参数错误
基于API文档中的异常列表进行响应返回。表明参数非法,需要调用方法加强参数合法性校验
- 业务错误
基于非约定返回对应code与消息
####3. RPC Service接口响应
* 内部异常
返回服务不可用消息
- 参数错误
基于接口文档进行响应,直接返回异常堆栈
- 业务错误
直接返回异常堆栈
checkedException 与uncheckedException 声明原则
-
- 如果是参数非法抛出,返回结果非法(即软件BUG) uncheckedException
-
- 如果你认为调用方 程序员 需要有意识地采取措施,那么抛出检查型异常。
-
- 程序产品有明确的条件约束的要求,可声明检测型业务异常
统一对异常进行分类处理
- 异常转换
- 异常信息处理
- 逻辑断言
- 参数合法性验证
- 返回结果合法性验证
异常捕获
统一对异常进行拦截处理
* 目的:防止不明确的异常流出系统
* RPC Service 响应拦截
* Web Control 响应拦截
* Http API 响应拦截
常见的错误的异常处理方式
- 直接勿略异常
try { new String(source.getBytes("UTF-8"), "GBK"); } catch (UnsupportedEncodingException e) { e.printStackTrace(); }
- 正确的处理
try { new String(source.getBytes("UTF-8"), "GBK"); } catch (UnsupportedEncodingException e) { throw new RuntimeException("环境不支持UTF-8",e) }
- 业务异不提供任何信息
public class DuplicateUsernameException extends Exception { }
- 给每个异常处理都定义一个Code,用一个统一异常替代所有业务异常
public class ServiceException extends RuntimeException { public ServiceException(Exception e) { super(e); } public ServiceException(String message) { super(message); } }
错误:
1 、必须明确定义业务异常
2、 尽可能申明成checkedException 3要带上具体的业务数
正确方式:定义明确的业务异常
PS:健壮的系统异常的判断尤为重要,不要认为开发完成就完成了,其实在开发过程中,就像装修一样『前门』很光鲜,『后门』也得控制好。万一别人没从『前门』进来,要求让带个钥匙进门,结果拿个斧子进『后门』呢?
>>原创文章,欢迎转载。转载请注明:转载自IT人故事会,谢谢!
>>原文链接地址:上一篇:已是最新文章
以上所述就是小编给大家介绍的《『互联网架构』软件架构-java日志异常(18)》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 『互联网架构』软件架构-解密电商系统-互联网BAT商品详情缓存架构(82)
- 『互联网架构』软件架构-分布式架构(14)
- 『互联网架构』软件架构-电商系统架构(上)(69)
- 『互联网架构』软件架构-电商系统架构(中)(70)
- 『互联网架构』软件架构-电商系统架构(下)(71)
- 『互联网架构』软件架构-电商系统架构发展历程(68)
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Python网络编程基础
John Goerzen / 莫迟 等 / 电子工业出版社 / 2007 / 68.00元
《Python网络编程基础》可以作为各层次Python、Web和网络程序的开发人员的参考书,在实际工作中使用书中的技术,效果更佳。一起来看看 《Python网络编程基础》 这本书的介绍吧!