码出高效系列（二）之异常与日志

一时失言乱红尘 2022-01-30 08:39 234阅读 0赞

### 码出高效系列（二）之异常与日志 ###

1.  应用中不可直接使用日志系统（Log4j、Logback）中的API，而应依赖使用日志框架SLF4\]中的API，使用门面模式的日志框架，有利于维护和各个类的日志处理方式统一。

import org.slf4j.Logger；
    import org.slf4j.LoggerFactory；
    private static final Logger logger = LoggerFactory.getLogger（Abc.class）；

1.  异常不能用来做流程控制、条件控制。因为处理效率比条件判断方式要低很多
2.  不能在finally 块中使用return。finally块必须对资源对象、流对象进行关闭操作，如果有异常也要做try-catch操作。有try块放到事务代码中，catch异常后，如果需要回滚事务，一定要注意rollback事务。
3.  捕获异常与抛异常必须完全匹配，或者捕获异常是抛异常的父类。
4.  日志文件推荐至少保存15天，因为有些异常具备以“周”为频次发生的特点。
5.  应用中的扩展日志（如打点、临时监控、访问日志等）命名方式：  
    appName\_logType\_logName.log。logType：日志类型，推荐分类有stats/desc/monitor/visit等；logName：日志描述。这种命名的好处：通过文件名就可知道日志文件属于什么应用，什么类型，什么目的，也有利于归类查找。.
6.  避免重复打印日志，浪费磁盘空间，务必在1og4j.xml中设置additivity=false。
7.  异常信息应该包括两类信息：案发现场信息和异常堆栈信息。如果不处理，那么通过关键字throws往上抛出。
8.  谨慎地记录日志。生产环境禁止输出debug日志；有选择地输出info日志；如果使用warn来记录刚上线时的业务行为信息，一定要注意日志输出量的问题，避免把服务器磁盘撑爆，并记得及时删除这些观察日志。  
    说明：大量地输出无效日志，不利于系统性能提升，也不利于快速定位错误点。记录日志时请思考：这些日志真的有人看吗？看到这条日志你能做什么？能不能给问题排查带来好处？
9.  可以使用warn日志级别来记录用户输入参数错误的情况，避免用户投诉时，无所适从。注意日志输出的级别，error 级别只记录系统逻辑出错、异常等重要的错误信息。如非必要，请不要在此场景打出error级别。
10. 方法的返回值可以为null，不强制返回空集合，或者空对象等，必须添加注释充分说明什么情况下会返回null值。调用方需要进行null判断防止NPE问题。
11. 防止NPE，是程序员的基本修养，注意NPE产生的场景：  
    1）返回类型为基本数据类型，return包装数据类型的对象时，自动拆箱有可能产生NPE。  
    2）数据库的查询结果可能为null。  
    3）集合里的元素即使isNotEmpty，取出的数据元素也可能为null。  
    4）远程调用返回对象时，一律要求进行空指针判断，防止NPE。  
    5）对于session中获取的数据，建议NPE检查，避免空指针。  
    6）级联调用obj.getA（）.getB（）.getC（）；一连串调用，易产生NPE。  
    使用JDK8的optional类来防止NPE问题.
12. 在代码中使用“抛异常”还是“返回错误码”，对于公司外的http/api开放接口必须使用“错误码”；而应用内部推荐异常抛出；跨应用间RPC调用优先考虑使用Result方式，封装isSuccess（）方法、“错误码”、“错误简短信息”。
13. 避免出现重复的代码（Don’t Repeat Yourself），即DRY原则。  
    说明：随意复制和粘贴代码，必然会导致代码的重复，在以后需要修改时，需要修改所有的副本，容易遗漏。必要时抽取共性方法，或者抽象公共类，甚至是组件化。