Seven rules for recording abnormal logs

Recently I have been helping to debug some of the biggest bugs, so I realized the importance of recording exception logs for simplified debugging. I have summarized some best practices for recording exception logs.

1. Record technical exceptions rather than user exceptions

User exceptions (for example, "the login user name already exists") are not displayed to the user, either leave nothing to worry, or it is not an exception ("the user has not been authenticated "). Technical exceptions (for example, "file storage is insufficient and you cannot subscribe to this product") are what you need to debug and respond, if you record everything, it is very likely that the log entity is too long to be truly reflected in the exception log you recorded. You should find out the cause of each exception in the log file ("Is it a bug?"). Excessive exceptions will lead you to treat the exception rashly ("amount, just a common exception ").

2. store data in exceptions for easier recording

"There is no way to charge account fees." You should store the exception context like what JUnit does ("expectation... But get ...") This makes debugging easier.

The cannotchargemoneyaccountexceptionmoney (moneyinaccount, money tocharge, account Account) clause can be understood as: "An attempt to collect an account 1234567890 EUR, but only 10 EUR is available" relative to "deduction failed ", this makes it easier to record exceptions in a meaningful way later.

3. Record abnormal descriptions

The bad example is Sun: classcastexception. It cannot display any classes you want to convert. Now we can even find that:

final String s = "Hello";final int x = (Integer) s;

We will tell you at Compilation:

 T.java:4: inconvertible types   found   : java.lang.String   required: java.lang.Integer            final Integer x = (Integer) s;

Exception thrown by Java during runtime

  Exception in thread "main" java.lang.ClassCastException:    java.lang.String cannot be cast to java.lang.Integer

This is better than the former.

4. Cause of output exceptions

If there is a packaging method in the exception as the cause of the exception, record all causes. Some log frameworks have already helped you do this, and some have not yet, so make sure that all causes of exceptions are recorded in the log file, ensure that the beginning of all relevant stack tracing information is recorded in your file, rather than in disorder.

5. Select a reasonable log level

If your exception is critical, record it as level. critical, if you need to determine what critical means to you (usually money loss), for example, if a pre-defined function is invalid or users cannot register due to technical issues, then you have a critical problem to solve. Critical exceptions in log files are monitored because you are suffering losses. Has your own exception implementation iscritical () or criticalexception interface, and records exceptions to files using encapsulation classes and correct log levels. If your log framework cannot find a reasonable level, create it.

6. Do not record it and then throw it out again

Record the log and throw an exception again. This is an anti-pattern ).

catch (NoUserException e) {       LOG.error("No user available", e);       throw new UserServiceException("Nouseravailable", e);}

Do not do this. Your log file contains the same exception several times at the stack level. Remember to record it only once.

7. Do not use system. out or system. Err record

Using the log framework, it can be better processed than you

We hope these rules can help you with exception logs and make debugging easier.

Original English text: codemonkeyism, compilation: importnew-Liu Zhijun
Http://www.importnew.com/518.html.

Seven rules for recording abnormal logs