本文收藏自网络
1、 只记录技术上的异常，不记录用户异常
像“用户名已存在”这种异常是不用记录的，但是你需要把它们展示给用户。你需要记录的是类似“磁盘已满”这种技术上的异常，并对这些异常进行相应的处理。如果你把所有的异常都记录到你的日志中，那么你会因为有太多的异常记录，而无法对你日志文件中的异常做出有效处理。你需要研究日志文件中的每一个异常，猜测造成它的原因（“这是个bug吗？”）。太多的异常会让你对日志文件中的日志形成一种草率的心态（“啊哈，不就是个异常嘛”）
2、 在你的异常类中存储数据以便于日志记录
比如说，“不能从账户中取钱”这个异常，你应该像junit那样（“excepted but got …”）去记录异常信息，以便于调试。
CannotChargeMoneyAccountException(Money moneyInAccount, Money toCharge, Account account)
提示信息可以是：“视图从账户‘1234’中取20欧元，但是仅有10欧元可用”。相比“取钱失败”，这样做使得用针对性的方式来处理异常变得更加简单
3、 记录异常的详细描述
JDK中有一个非常负面的例子：ClassCastException长久以来就没有告诉你要把一个对象转型成什么类时发生的异常。
现在它甚至检测了：
final String s = "Hello";
final int x = (Integer) s;
然后告诉你：
T.java:4: inconvertible types
found : java.lang.String
required: java.lang.Integer
final Integer x = (Integer) s
现在运行时java抛出的异常如下：
Exception in thread "main" java.lang.ClassCastException:
java.lang.String cannot be cast to java.lang.Integer
比以前好多了。
4、 输出所有导致异常发生的原因
如果你的异常是一个封装了诱因的异常，那么在异常中记录所有的诱因。有些日志框架已经为你做了这些，而有些却没有。一定要在你的日志文件中记录所有的原因。
5、 按正确的级别记录
假设你的异常是致命的，那么以Level.Critical级别来记录。你需要自己定义致命对于你来说意味着什么（很多时候它意味着钱少了）。
比如说，假设一个功能不起作用了，或者因为技术问题一个用户不能注册了，这时就有一个致命的问题需要你去解决了。
为致命问题监控日志文件，你的钱正在流失。
实现isCritical()方法的异常类或者一个CriticalException接口，然后检测记录异常时是否按正确的级别进行记录。如果你的日志框架中没有合适的级别，生成一个
6、 不要记录后又抛出一个异常
记录日志又抛出一个异常是异常反面模式（注：就是反面教材的模式）
catch (NoUserException e) {
LOG.error("No user available", e);
throw new UserServiceException("No user available", e);
}
不要这样做。不然你的日志文件中会对同一个异常在不同的堆栈记录几次。只记录一次异常。
7、 不要用System.out or System.err来记录日志
使用日志框架，它能比你更好的处理记录日志。