Common log Log printing problems with Java encoding

Objective

This article summarizes some of the issues that the author encounters in Java Code view about log printing, and gives suggestions for modification. Due to limited capacity, inevitably there are errors and omissions, welcome correction.

a . nonstandard exception printing

When using the SLF4J log component, Logger.error (and Log.warn) accept the Throwable parameter to print the exception name and detailed stack information (possibly internally called E.printstacktrace ()).

But when you write a print statement, you need to be aware of the format. For example:

1 logger.error ("Best print:", e); 2 // A. 3 logger.error ("Bad print:" + e);   // B. or + e.tostring ()4//C. Or: {} ", E.getmessage ())

A sentence can still print the exception name and stack information, but more output a pair of curly braces "{}"; b. Only the exception name is printed, and the C clause prints the exception message string. Take the null pointer exception (runtime exception) as an example, the B sentence prints "java.lang.NullPointerException", and the C sentence prints "null" (too primitive).

You can use the following regular expressions to troubleshoot irregular print in Java code:

^\S*[LL][OO][GG] (ger| GER) *\. (Error|warn) \ ("(. +?)" \s*\+\s* (e|ex|e.getmessage\ (\)) \s*\);. *

The regular expression can be used to troubleshoot print defects such as the B and C sentences above. Given the differences in the actual code writing style, there will be a small number of false negative and miscalculations. Also note that some exceptions, such as SQL or IO exceptions, may leak sensitive information and should be "processed" according to network security requirements before printing the exception stack.

Two. Non-standard variable printing

When using the SLF4J log component to print variables, it is recommended to use the "{}" placeholder style (c-style) instead of the "+" stitching (c + + style). For example:

1 // placeholder 2 logger.error ("Country:" +ctry+ ", Province:" +prov + ", City:" +city ");   // Stitching characters

Obviously, the placeholder style is more intuitive, and it's not easy to get a typo--there's a problem with the stitching on the top, who can find it?

However, the most common problem with variable printing is when you print without a placeholder or a splice character:

1 logger.error ("Print cannotbeprinted:", cannotbeprinted);  // wrong 2 logger.error ("Print canbeprinted:" + canbeprinted);  // Good 3 // Better

Note that cannotbeprinted or canbeprinted are non-throwable variables. That is, the exception variable e does not apply to the above rules, but E.getmessage () applies.

You can use the following regular expressions to troubleshoot non-canonical variable printing in Java code:

^\S*[LL][OO][GG] (ger| GER) *\. [A-za-z] {4,5}\ ("([^ ({})]+?)" \s*\,\s* ([^e\s]|\w{2,}) \s*\);. *

Given the differences in the actual code writing style, the regular expression has false negative and false positives. For example, "Logger.error (" Best print: ", ex);" will be misjudged.

three . more than the DEBUG level judgment

When you use the SLF4J log component to print at the debug level, isdebugenabled () is called inside the Debug () method to determine the debug level. Therefore, the judgment in the following code is not necessary:

if (logger.isdebugenabled ()) {    logger.debug (new  object[] {changes, usetime});}

four. declaration of log Object logger

It is generally recommended that the log object logger be declared as private static final. Declaring private can prevent logger objects from being used illegally by other classes. Declaring static prevents duplication of new logger objects, wastes resources, and prevents logger from being serialized, creating a security risk. The declaration is final because there is no need to change logger during the life cycle of the class.

However, the actual coding can be slightly adapted to the usage scenario. For example, a static final member variable usually requires uppercase (such as logger), and if you feel it is awkward, you can remove the final decoration. Another example is the expectation that the logger object can be reused, as defined below:

protected Final Logger Logger = Loggerfactory.getlogger (this. getclass ());

In this way, subclasses can directly use the inherited Logger object to print the output without having to GetLogger () to get the log object again.

Five. log level should be reasonable

If the log is not level or level unreasonable, then locating the problem can not quickly and effectively block a large number of low-level information, to quickly locate the difficulty. It is recommended that the logs related to specific implementations use the debug level, the general business processing logs with the info level, do not affect the business errors with the warn level, and the logs that log exceptions or important errors should be error-level.

Common log Log printing problems with Java encoding