Exception management is completed by the isline. exceptionprocess. exceptionprocessprovider namespace.
System logs and system exceptions are recorded separately. ilfw processes system logs and exceptions separately to improve system flexibility and security. Predictionprocessprovider is an applicationProgramThe main component that requires interaction. It is used to generate exception messages. The generated exception messages are not directly displayed and will be output only after formatting by layout in advance.
The exception module is attached to isline. applog. applogprovider and exception modules are designed as special system logs. Therefore, the applog module must be configured first when the exception module is used. For details, see aicken.Article.
After configuring the Log Module, You need to introduce the above namespace and use the "add" label in Web. config to add an exception pointer:
<Add key = "isline. exceptionprocess. configuration. rendername" value = "oracleusingsprender"/>
This pointer indicates the Renderer used by the exception module. The Renderer name is value. When the module is loaded, isline is automatically loaded. the "Renderer initialization" module in the applog namespace loads the specific exception object only after the Renderer is initialized.
This configuration process is described as follows. If we need to record the exception information to a text file, and then find that the exception is very important, and we need to write it into the database for saving, then we need to modify the Web. config file in this way.
1. Add the following node sectiongroup name to <configsections> </configsections>: "filerender" and "oracleusingsprender"
2. Add the corresponding render configuration content between </configsections> <appsettings>.
3. Use
<Add key = "isline. exceptionprocess. configuration. rendername" value = "oracleusingsprender"/> indicates the log model for abnormal use. "Oracleusingsprender" is the name of one of the two log models we specified in step 1. Now all the exception information in the system is written to the media described in the "oracleusingsprender" model.
At this moment, the boss suddenly said that the exception does not need to be recorded in oralce, so you can record the text file. Well, we only need to change the name of the exception Renderer, change "oracleusingsprender" to "filerender", so that exceptions in the system are automatically redirected to text files. The path of the text file is described in the "appenderinf" label, and the record content is described in the "appendercontent" label.
Configuration of the above processCodeRefer to the author's blog.
System exception records
The namespace records the exception information in the system. the "exception" Object in. NET is directly thrown to exceptionprocessprovider. The provider automatically converts the exception type to the "logentity" mentioned earlier and writes it to the corresponding media, the corresponding media and other information can be the same as the log node, or you can use a separate node without affecting each other.
The usage of another standard predictionprocessprovider is recommended. As mentioned above, during system design, I usually establish a business entity model, business event model, and business message model in advance, the business entity model includes the business model and exception model. The design of the exception model is completed in the system design phase. It pre-defines possible errors during system operation and creates models for these errors.
Each custom exception model must inherit the exceptionentity base class and implement the iexceptionprocess interface. This not only quantifies system exceptions, but also effectively manages system exceptions and enhances system security. When the exception module is called at the upper layer, you do not need to use the writelog () method. When a catch detects a system exception, the exceptionprocessprovider automatically blocks the exception and enters the process of the ilfw exception module.
The isline framework currently supports two exception record modes:
- An error occurred while using the ilexception class.
This method is the simplest method. After simple information configuration of Web. config, you can directly intercept and record exceptions in the program, but the disadvantage is that you need to traverse various exceptions. The code for this method is as follows:
Try
{
String I = "I ";
Response. Write (I );
}
Catch (exception ex)
{
Ilexception Ile = new ilexception ();
Ile. writelog (Ex );
}
2. Use custom exception to record exception information
The custom exception record method is a standard OOP principle. You need to quantify each exception in the system design phase and model these exceptions. All model classes must inherit the ilexception class, and implement the writelog () method.
The implementation of the writelog () method can directly call the writelog (Ex) Implementation of ilexception within the exception class, which is very simple.
Then you can use the following code to use this exception management module:
Try
{
String I = "I ";
Response. Write (I );
}
Catch (ilexception ex)
{
Ex. writelog (Ex );
}
Because exceptions are defined in advance, the system does not have to traverse the exception tree. Therefore, this method has high performance and embodies the principles of abstraction and encapsulation.
In addition to the record function, the system exception module also has an important function: exception display, that is, what page is displayed to the user after a system exception occurs. Displaying a user friendly page is required as follows:
● Display to user-friendly pages can reduce user anxiety and improve user experience.
● Hiding system exceptions to prevent leakage of code, paths, and other technical information to improve system security.
● Unified management of system running exceptions helps improve the overall quality of software and facilitate overall control.
The display type of the friendly page is also based on the configuration node information. The Administrator only needs to change the enumeration value in the configuration node to change the user experience page. There are 10 methods on the user experience page, these methods are used to throw the original exception information, throw custom exception information, throw simple information (excluding exceptions), and hide exception information.
In the system development phase, you can display the original exception information. After the system is deployed, you can throw simple information (excluding exceptions) or hide the exception information, you can also choose whether to log to the log media when you select these display methods.
The exception module provides the above functions perfectly. You can choose whether to record specific content to the log and determine the recording media. You can also choose, how to present it to the user. The isline framework provides multiple exception recording methods for system developers. These methods can exist at the same time. As long as you have the need, you can record exceptions of different businesses to different media; it also provides a unified exception display mode for the system. system exceptions are returned to users in a unified manner. Exception records and presentations can even be determined in the system requirement analysis phase of software engineering, which is more conducive to monitoring system operation.
This article has been published simultaneously in the software report and cannot be reproduced by any personal media.