异常怎么记录

一个正常的业务异常的级别应该是哪个?

现如今的项目里，正常的业务异常会以 INFO 记录，或者以 WARN。

其中一个原因是，监控平台监控的一般是 ERROR 或者 WARN 级别，如果把业务异常会以 ERROR 级别记录，明显不符合监控平台的需求。

所以我当初觉得把异常以 INFO 记录虽说别扭，但也觉得这好像是合理的，但如今一想其实我们错在不应该以在监控平台以 ERROR 级别监控。

而应该以 FATAL 级别记录系统出现 BUG 或者其它严重情况，因为在日志级别里 FATAL 级别才意味着系统出现问题，而 ERROR 仅仅是代表着

出现异常了，这样才更加符合规范。

另外我觉得一般情况下业务异常的 ERROR 日志也没必要单独记录到一份文件里，因为这样会缺失一个上下文的分析日志环境，因为业务异常一般都跟整个

流程有关，只有通过整个流程的日志记录才能分析的出来这个异常是否合理，但一般系统底层 BUG 之类的单独记录日志会比较好一些，因为此类异常一般与具体业务

场景及流程无关，如果与业务流程的日志放到一起反而难以查找，因为业务相关的日志估计占到日志的九成九以上。

用模块级别的 logger

现今项目有多个模块，每个模块基本上是一个模块相关的 logger 和 Exception（后话） 通吃一切，在log的配置里，记录了模块名，却没记录类名，无形之中

就将日志的定位放大到模块级别，根本就无法定位到某个类，除非出现异常，但正常的的日志根本就不知道在哪里记录的，然后就只能搜索代码自行定位。

日志的记录文件，按模块来，每个一份，然后有一些总的什么 root、all之类的文件记录，在查找日志时非常麻烦，按模块的记录的文件，明显都是整个流程中的

一部分，即便是root、all之类的也记录的不全，所以日志文件存在：重复式记录、一个流程的日志不在一个文件里。

工具类里记录日志

工具类里不应当记录日志，如果工具类抛出了运行时异常，那么一般就是程序 bug 了，此异常应当由顶层捕获记录。

工具类应当可抛异常但不记录，如果说是想捕获后忽略此异常，但又想记录下以防万一，那么我觉得还是直接抛出的好，

因为有此种需要表明其一旦产生此异常就是一个程序 BUG，不应当被忽略。如果是业务需要，那么应当在业务层处理，

按照业务需求忽略并记录此异常。