What happens to the program: How logging works and how----log in a program

Reprint Address: Http://www.infoq.com/cn/articles/why-and-how-log

Logging in a program typically has two purposes: Troubleshooting (fault location) and display program running status. Good logging can provide us with enough information on how to locate problems. Logging can be considered simple, but it is not easy to use the log to efficiently locate the problem. Here are the following three aspects of the content, supplemented by code examples, summed up how to write a good log, hoping to inspire and help others: how to log can facilitate troubleshooting (fault location) program running status can be remembered which should avoid how the log way How to keep a diary is convenient for troubleshooting.

1. External Call Encapsulation

In the program, the external system and module rely on the call before and after logging, convenient interface debugging. When something goes wrong, you can quickly sort out what the problem is.

1.  Log.debug ("Calling External System:" + parameters);

2.  Object result = null;

3.  try {

4. Result      = Callremotesystem (params);

5.      Log.debug ("called successfully"). Result are "+ result);

6.  catch (Exception e) {

7.      Log.warn ("Failed at calling XXX System". Exception: "+ E);

8.  }  

2. State Change

Changes in important state information in the program should be recorded to facilitate the restoration of the site when the problem is checked, to infer the program running process

1.  Boolean isrunning;

2.   

3.  isrunning = true;

4.  Log.info ("System is running");

5.   

6.  //...

7.   

8.  isrunning = false;

9.  Log.info ("System is interrupted by" + Thread.CurrentThread (). GetName ());

3. System entrance and exit:

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

1.  void execute (Object input) {

2.      log.debug ("Invoke parames:" + input);

3.      Object result = null;

4.       

5.      //business Logic

6.       

7.      Log.debug ("method Result:" + result);

8.  }  

4. Operational anomalies:

Any business exception should be written down:

1.  try {

2.      //business Logical

3.  catch (IOException e) {

4.      log.warn ("Description xxx", e);

5.  catch (Businessexception e) {

6.      Log.warn ("Let me know Anything");

7.  catch (Exception e) {

8.      log.error ("Description xxx", e);

9.  }

10.   

5. Non-expected implementation:

Print the log where it is possible for the program to be executed. If I want to delete a file, the result returns success. But in fact, that file doesn't exist until you want to delete it. The end result is the same, but the procedure has to let us know this, to find out why the file did not exist before it was deleted

1.  int myvalue = xxxx;

2.  int absresult = Math.Abs (myvalue);

3.  if (Absresult < 0) {

4.      log.info ("Original int" + myvalue + "has nagetive abs" + absresult);  
5.  }  

6. An else situation that is rarely seen:

else may swallow your request, or give an incomprehensible final result

1.  Object result = null;

2.  if (running) {

3. Result     = xxx;

4.  } else {

5. Result     = YYY;

6.     Log.debug ("System does not running, we change the final result");

7.  }  

what the program's running state can remember.

The program is running like a robot, we can see from its log what it is doing, is not in accordance with the expected design, so these normal running state is to have.

1. Program Running time:

1.  Long starttime = System.currenttime ();

2.   

3.  //Business logical

4.   

5.  log.info ("Execution Cost:" + (System.currenttime ()-StartTime) + "MS");

2. Progress in the implementation of mass data:

1.  Log.debug ("Current Progress:" + (Currentpos * 100/totalamount) + "%");

3. Key variables and what are the important things being done:

Perform key logic, do IO operations, etc.

1.  String Getjvmpid () {

2.     String pid = "";

3.     //obtains JVM process ID

4.     log.info ("JVM pid is" + pid);

5. return     pid;

6.  }

7.   

8.  void Invokeremotemethod (Object params) {

9.      Log.info ("Calling remote method:" + params);

    //calling Remote Server

1.}  

What kind of log method should be avoided.

1. Confusing information with log

The log should be clear and accurate: when you see the log, you know it is because the connection pool is not connected to the problem.

1.  Connection Connection = Connectionfactory.getconnection ();

2.  if (connection = null) {

3.      Log.warn ("System initialized unsuccessfully");

4.  }  

2. Mistaken position

In the product code, logs are logged with the console, causing the log to not be found.

1. catch (ConfigurationException e) {

2.    e.printstacktrace ();    

3.}

3. Error level

The error level often occurs, common such as: Confusing code errors and user errors, such as login system, if malicious login, the system will appear too many warn, so that administrators mistakenly think it is a code error. Users can be fed the error, but do not record the user error behavior, unless you want to achieve control purposes.

1.  Log.warn ("Failed to login by" +username+ ");

4. Missing information

There are two possible scenarios:

1 Users write less information themselves, resulting in no reference value;

2 The way the user calls log causes the loss of information, as in the following example, no stack trace.

1.  } catch (Exception ex) {    

2.   Log.error (ex);    

3.  }

Summary:

Logging in the programmer's day-to-day programming practice must face things, this article on the topic of their own experience, I hope that readers can gain. Please forgive me if you have more than enough.