When we are developing a Web project, it is often the case that debugging locally is normal, but not deployed to the server. A large part of this is due to the fact that the service environment is different from the local The configuration of the database and the Server Software environment. How to accurately and quickly judge the location of the problem? I have summed up my usual three ways.
First: by experience. Of course, the business logic will be very clear, the page execution to what extent, where there may be errors, by experience can guess where the error can be. This approach relies on the experience of the programmer.
Second: Let the application report the Yellow pages, displays a specific error message. This method can be very intuitive to see the error of the program. But if it is a formal environment, the procedure is impossible to appear in the yellow pages of the situation, users see the wrong Yellow pages for managers is simply a nightmare. You will generally skip to a custom error page, Displays information such as system errors. In this case, the second method is not workable.
Third: Log error logs. Use the try catch mechanism to capture the error message, and then log the error message in the journal for later lookups. Obviously the third method is the best way, and the implementation of this approach is generally divided into two types:
One: The component that writes this record log.
Two: Use of third-party components, such as: Log4net.
Both of these methods are feasible, it doesn't matter what you need to be able to meet your needs. Using a third party component to make it simple, here's the log4net application. This component was there a few years ago, but I didn't use it. Now in the project is found its existence, To know the importance of it. First of all, the advantages of log4net components:
First: Support a variety of logging methods, can be divided into mail form, text form, database storage, and so on.
Second: In the case of large concurrency is very good to solve the problem of writing the same file.
Third: Different log files can be generated based on date and file size.
Four: The configuration is relatively simple, the invocation is also convenient.
There have been many friends in the garden have written log4net articles, I am a teachable, and now just want to share the experience of using log4net. It can be said that the application of a nagging bar.
To take advantage of log4net, I divide it into three steps:
First: Reference the Log4net component in the project.
Second: Configure log4net, generally written in web.config.
Third: the call section.
Specifically how to configure, I do not want to say, the official document has been written too clearly, nor is it the focus of this article. Here's my experience and share with you: