Functions and methods of logging

Logging in the program generally has two purposes: Troubleshooting and display the program running state. A good logging method can provide us with a sufficient number of positioning problems. Logging can be considered simple, but how to efficiently position the problem through the log is not a simple matter. Here are the following three aspects of the content, supplemented by code examples, summarize how to write a good log, hoping to inspire and help others:

• How to remember the log can be convenient troubleshooting
• Program run status can be remembered which
• What logging methods should be avoided

How to remember log can be convenient troubleshooting?

1. Encapsulation of external calls

In the program, the External System and module of the dependent calls before and after the log, convenient interface debugging. You can quickly sort out what's going on when something goes wrong.

Log.debug ("calling External System:"+parameters); Object result=NULL; Try{result= Callremotesystem (params); Log.debug ("called successfully. Result is"+result); } Catch(Exception e) {Log.warn ("Failed at calling XXX system. Exception:"+e); }  

2. Status changes

The changes of important state information in the program should be recorded to facilitate the restoration of the scene when the problem is checked, and the procedure is inferred.

boolean isrunning;       true ;    Log.info ("System is running");         // ...         false;    Log.info (""

3. System entry and exit:

This granularity can be an important method level or a module level. Record its input and output for easy positioning

  void Execute (Object input) {        log.debug ("" + input);         NULL ;                 // Business Logic              log.debug ("" + result);  

4. Business Exceptions:

Any business exception should be written down:

 Try {        //Business Logical}Catch(IOException e) {Log.warn ("Description xxx", E); } Catch(businessexception e) {Log.warn ("Let me know anything"); } Catch(Exception e) {log.error ("Description xxx", E); } 

5. Unintended implementation:

Print the log for the program where it is possible to do so. If I want to delete a file, the result returns successfully. But in fact, that file doesn't exist until you want to delete it. The end result is consistent, but the procedure has to let us know, to find out why the file didn't exist before it was deleted.

  int myvalue = xxxx;     int absresult = math.abs (myvalue);     if 0 ) {        log.info ( "" "" +  Absresult);    }  

6. Rarely seen else cases:

else may swallow your request or give a hard-to-understand final result

  NULL ;     if (running) {       = xxx;     Else {       = yyy;       Log.debug ("System does not running, we change the final result");    }  

What can the program run state remember?

The program runs like a robot, and we can see from its log what it is doing, whether it is doing as expected, so these normal running states are needed.

1. Program Run Time:

long startTime = system.currenttime ();         // Business Logical         log.info ("" ""ms");

2. Progress in the execution of high-volume data:

Log.debug ("%"% "

3. Key variables and what are the important things you are doing:

Execute key logic, do IO operations, etc.

string Getjvmpid () {string PID=""; //obtains JVM process IDLog.info ("JVM pid is"+pid); returnpid; }        voidInvokeremotemethod (Objectparams) {Log.info ("calling remote method:"+params); //calling remote server}

What kind of log method should be avoided?

1. Log of confusing information

The log should be clear and accurate: when you see the log, do you know because the connection pool does not get the connection caused by the problem?

Connection Connection = connectionfactory.getconnection ();    if NULL {       Log.warn ("System initialized unsuccessfully");    }  

2. Mistaken location

In the product code, logging is logged using the console, causing no logs to be found.

   Catch (ConfigurationException e) {         e.printstacktrace ();    }

3. Level of memory error

The error level often occurs, such as confusing code errors and user errors, such as logging in to the system, if the malicious login, the system will appear too many warn, so that the administrator mistakenly thought to be a code error. You can feed back the user with errors, but do not log user error behavior unless you want to achieve the purpose of control.

Log.warn ("+username+");

4. Missing information

There may be two situations: (1) Users write less information, resulting in no reference value; (2) The way the user calls log causes the loss of information, as in the following example, there is no stack trace.

    Catch (Exception ex) {       log.error (ex);    }

Summarize:

The log record in the programmer daily programming practice must face the thing, this article talks about this topic to own experience, hoped that the reader can have the benefit. More than enough, please forgive me.

Functions and methods of logging