记录异常的规则

在出现问题时，好的异常记录能让我们快速的定位问题所在，甚至可以仅仅通过日志文件就能查出原因。虽说日志记录如此重要，但在实际项目中却经常得不到足够的重视，所以转载一篇国外网站上关于日志记录规则的文章。翻译的不足之处请大家多多包涵。

 

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来记录日志 使用日志框架，它能比你更好的处理记录日志。

以下是原文

7 Good Rules to Log Exceptions December 16, 2008 by Stephan Schmidt 24 Comments I’ve been helping to debug some nasty problems and bugs lately. It occurred to me that some best practices on how to log exceptions go a long way towards easier debugging. Some of the best practices I’ve learned to log exceptions are compiled in this post. 1. Only log technical exceptions not user exceptions User exceptions are either ok and need not to be logged (“login name already exists”) but shown to the user, or no exception at all (“user has no credit left”). Technical exceptions are those you need to debug (“no file storage left”, “could not book product”) and react to. If you log everything you will probably get too many log entries to have a meaningful reaction to exceptions in your log. You should inquire into every exception in your log files and find the cause for it (“is it a bug?”). Too many exceptions will make you sloppy with exceptions in your log files (“nah, just another exception”). 2. Store data in your exceptions to make them easier to log Taking the exception “could not charge money from account” you should store the context of the exception just like Junit does (“expected but got …”) to make debugging easier CannotChargeMoneyAccountException(Money moneyInAccount, Money toCharge, Account account) The message could be: “Tried to charge 20 EUR from account 1234567890 but 10 EUR available” compared to “Charge failed”. This makes it much easier later to log the exception in a meaningful way. Be careful to create no memory leaks though. 3. Log the description of your exception Very bad example from Sun: The ClassCastException didn’t show you what class you did want an object to cast to for a long time. Now it even detects final String s = "Hello"; final int x = (Integer) s; and tells you T.java:4: inconvertible types found : java.lang.String required: java.lang.Integer final Integer x = (Integer) s; During runtime the exception thrown by Java is now: Exception in thread "main" java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer Much better than before. 4. Output all causes to your exception If your exception has an exception wrapped as a cause, log all causes. Some logging frameworks do this for you, some don’t. Be sure to have all causes of your exception in the log file. Be sure the beginning of all relevant stack traces in your log, not scrambled ones. 5. Log to the right level If your Exception is critical, log it as Level.CRITICAL. You need to decide what critical means for you (most often it means losing money). For example if a booking didn’t work, or a user could not register due to technical problems then you have a CRITICAL problem you need to solve. Monitor your log files for critical exceptions. You’re losing money. Have your own exception implement isCritical() or a CriticalException interface and test when logging the exception in your wrapper to log it on the right level. If your logging framework hasn’t got an appropriate level, create one. 6. Don’t log and rethrow Logging and rethrowing an exception is an exception anti-pattern. catch (NoUserException e) { LOG.error("No user available", e); throw new UserServiceException("No user available", e); } Don’t do it. Your log files will then contain the same exceptions several times on several stack levels. Only log the exception once. 7. Do not log with System.out or System.err Always use a log framework, it can handle logging better than you. I hope those rule help you with your exception logging and enable you to easier debug your problems. Thanks for listening. As ever, please do share your thoughts and additional tips in the comments below, or on your own blog (I have trackbacks enabled). Update: For some Hackernews comments: Logging everything is fine but leads to ~50gig/day, 300gig/week, 1.2tb/month log files for a moderate site. Your grep won’t work very good for that. Splunk will obviously help of course but is only free for 0.5gig/day, a 1/100 of the log files you will get. You can leave a Reply here. Of course, you should follow me on twitter here.

转自:http://codemonkeyism.com/7-good-rules-to-log-exceptions/