1.背景介绍
写接口的时候,经常会有对service的操作,那service操作之后返回的结果该如何处理呢?
主要有以下三个问题:
对Service返回的结果是否要判空，为什么？
Service返回的结果是否需要打日志,为什么?
如果需要打日志,应该打什么样的日志,为什么?
2.知识剖析
主要从软件设计原则中的健壮性入手来谈谈自己的理解
健壮性是软件设计时非常重要的一个指标,是指软件对于规范要求以外的输入情况的处理能力。所谓健壮的系统是指对于规范要求以外的输入能够判断出这个输入不符合规范要求，并能有合理的处理方式
通俗点说就是不能只考虑正常情况,还要考虑异常情况.而且根据"墨菲定律",只要你能想到某种异常情况可能会发生,那么这种异常情况就一定会发生.所以这时候对异常情况的处理就至关重要,必不可少.
3.三个问题的解决方案
问题一:对Service返回的结果是否要判空，为什么？
答案是:绝大多数情况下都需要对Service返回的结果进行判空.
通常调用service之后返回的结果有两种用途:
一种是作为下一个操作的入参.在这种情况下就必须要判空
另外一种是作为最后的结果返回.在这种情况下还需要继续细分;如果这个结果可以为空,那么就不用判断,直接返回,如果这个结果不能为空,那么还要继续判断,并要处理异常情况.
问题二:Service返回的结果是否需要打日志,为什么?
答案:需要.目前在项目中,所有的从Service返回的结果都要打日志.这个问题很好理解,日志是我们了解程序运行,问题追踪的工具.如果从Service返回的结果不打日志,以后出现问题,我们就不能快速的定位到问题所在.
问题三:如果需要打日志,应该打什么样的日志,为什么?
答案:视情况而定
一种情况是数据是一个基本类型或者对象类型,比如通过条件获取ID,或者根据Id获取对象等.
这时还要分两种情况
1.我只需要该对象的属性,比如是否为空,具体返回的数据的值是什么,我们不关心的,就不需要在日志中打印返回的结果的值(代码举例,userController,用户实名接口)
2.我除了要判断该对象的属性,还需要用到该数据的值,比如作为结果返回,或者是作为下一步操作的入参,那么就需要在日志中打印结果,以后如果出现问题,能够方便我们进行调试.
对于第二种情况一般是直接打印这个对象即可,但还要注意不能将用户的敏感信息打印出来,比如说密码,身份证号之类的敏感信息(代码举例,userController,用户实名接口)
另外一种情况是数据是一个集合类型,比如数组,List等.
这种如果没有特殊需求,只需要打印List的长度即可,不需要将所有的list中数据的具体值记录日志,因为这样会特别影响性能,而且打印长度基本也满足了我们对日志功能的需求.(代码举例,producController,查询产品列表接口)
思考:日志应当包括哪些要素?
基本的日志起码要包括以下几个要素
日期,时间(有的要求高的还要提供毫秒信息和时区);会话标识;日志级别;日志内容
日志内容包括上下文,不要只有一个Error,或者success最好是能够简单描述一下原因(代码实例,productController)
4.参考文献
参考一：如何正确的打印日志
参考二：写给开发者：记录日志的10个建议
参考三：日志记录的作用和方法
8.PPT链接
