The .NET has a complete exception system, after an exception, we can write some code to handle exceptions. From other aspect, we need a very flexible and convenient unusual publisher to display some friendly information to the user. And log in the log. Because it is obvious, we don't want users to see something such as "violating the unique key constraint 'ix_country'. You can't insert a repetition key in the object 'Country'." If you let users see " System error: You cannot insert a repetitive record! This article records some information violates the uniqueness of the database, please check your record to maintain the uniqueness of the information. Please contact your system administrator! ", This is friendly Many, even if it is except that exception is not handled. At the same time, we also hope to write an abnormal information in the log to see these logs to view these logs to make corresponding processing. As you need, we may choose to write to the operating system log or in an XML file.
demand analysis
After understanding some of the above basic needs, let's make an analysis, see if you have such an exception publisher, you can add some features, that is, what is the complete demand.
1. After an exception, some friendly information is displayed to the user, not the original information that only programmers or system administrators can understand. The format of friendly information is similar to "system error: *************. Please contact administrator!".
2. Abnormal information is logged into the log, because this information is a sectoral or system administrator handling, so there must be as detailed information, at least, abnormal original information, error time, and more here.
3. The location of the log records, can be determined by the system administrator to write to the log of the operating system or an XML file, if it is an XML file, you want to define the storage location.
4. When displaying user information information to users, it should not be just no matter what exception will be displayed, and different friendly information should be displayed according to different exceptions.
5. An exception should be divided, and displayed and recorded according to different levels of exceptions to facilitate user and system administrators.
6. Multi-language features should be considered, and the information and logging of users from different languages are also different.
7. The exception matching information defined by the system administrator should be structural, hierarchical, for example, the system may not find "violating the unique key constraint 'ix_country'. You cannot insert a repetition in the object 'country'." Matching friendly information, but you should find the information that "violates the unique key constraint", even find the "System.Data.SqlClient.sqlexception" new exception, so that the system administrator defines more detailed, the match The more precise, and if it is not enough, the publisher can work properly.
Solutions
When an exception occurs, we first query matching exceptions in the exception matching data defined by the system administrator, if the query is unusual, then the user shows the friendly information defined in the exception, at the same time , According to the settings to record the abnormality information into the log or the specified XML file of the operating system. Since the abnormal Message is based on the culture of the current thread to display the information of the corresponding language, exception matching information should take into account this situation, and the user-friendly information displayed is also displayed in different languages according to the cultural properties of the thread. The location of the log file record can be set in the application configuration file. Abnormal level is also recorded in an exception matching information, which is OK. Structured, hierarchical abnormal matching information, requires a certain algorithm to search. Implementation process
When writing a specific algorithm to implement the above functions, let's take a look at the basic enumerations and data table structures used in it:
The first enumeration is an abnormal level, these enumerations match the type of operating system log, which is convenient to record the system log:
///
/// Event level
///
Public Enum EventLevel
{
///
/// Error event. It indicates a serious problem that the user should know (usually the loss of functionality or data).
///
Error,
///
/// Failure audit event. It indicates a security event that occurs when auditing access to the attempt failed (for example, an attempt to open files).
///
Failureaudit,
///
/// Information event. It indicates important and successful operations.
///
Information,
///
/// Successful audit event. It indicates a security event that occurs when auditing access attempts (eg, successfully logged in).
///
Successaudit,
///
/// Warning events. It indicates that there is no problem with immediate importance, but this issue may indicate the conditions that will result in problems in the future.
///
Warning
}
The second enumeration is the log save location, which is used to define the exception log of the program will be saved where, the system log, the XML file or both:
///
/// Abnormal log type
///
Public Enum CANUSEEXCEPTIONLOGTYPE
{
///
// Lage is saved in the XML file
///
XMLFile,
///
// Log Save in the system log
///
SYSTEMLOG,
///
// Log Save Location is all: XML file and system log
///
All
}
A dataset is custom universal information. There are some records for each language supporting system support. The record is some universal information, such as "system exceptions that may appear back to each exception", "request and system management Contact, there is also the information header of the information recorded in the log, such as "User Name:", "Error Time:", etc., these can be defined by the system administrator. The structure is as follows:
Let's explain in detail below:
Language: Language code, such as EN-US, ZH-CN PK
UnchartedExceptionMessage: The information displayed when you find the abnormality, such as "unknown error!"
ERROREXCEPTIONMESSAGE: Find the information that is notified when the error level is "error", notifying the user to display information when an exception is abnormal, such as "System Error"
ERRORPLEASEDOSMETHINGMESSAGE: Find the error level to "Error" to notify the user to display the information displayed in subsequent operation, such as "Please contact the administrator!"
FailureauditExceptionMessage: Find the error level to "Failureaudit" to notify the user information displayed when an exception is notified, such as "System Error" FailureauditpleaseDosomethingMessage: Find the error level to "Failureaudit" to notify the user to display information when the user is subsequently displayed, such as "Please contact the administrator!"
InformationExceptionMessage: Find the error level of "Information" to notify the user to display information when an exception is displayed, such as "System Error"
InformationPleaseDoSomethingMessage: Find the information displayed when the error level is "information", notifying the user, if you are in subsequent operation, such as "Please contact the administrator!"
SuccessAuditExceptionMessage: Find the error level to "SuccessAudit" to notify the user to display information when the user occurs, such as "System Error"
SuccessAuditpleaseDosomethingMessage: Find the information that is notified when the error level is "successAudit", informs the information displayed in subsequent operation, such as "Please contact the administrator!"
WARNINGEXCEPTIONMESSAGE: Find the error level to "WARNING" to notify the user to display information when the user occurs, such as "System Error"
WARNINGPLESEDOSMETHINGMESSAGE: Find the error level to "WARNING" to notify the user to display the information displayed in subsequent operation, such as "Please contact the administrator!"
LogtimeHeader: Information header of abnormal occurrence time
ExceptionTypeHeader: Abnormal type information head
ExceptiomoriginalMessageHeader: Abnormal original information information header
ExceptionSourceHeader: An exception application or object information header
ExceptionStackTraceheade: Unusual stack information head
ExceptionTargetsiteHeader: Method information of abnormal exception
ExceptionHelpLinkHeader: Exception Help Link Information Head
CustomMessageHeader: Abnormal system administrator custom information information header
CustomhelPlinkHeader: Exceptions System Administrator System Administrator Custom Help Link Information Head
UserNameHeader: Username Information Header
ExceptionInducedPathHeader: Module path information header
A data set is an exception matching table, which is defined by the system administrator, which is an exception that matches the record in this table to obtain user friendly information:
Let each field explain:
GUID: full sentence unique identifier PK
Language: Language code, such as EN-US, ZH-CN
EventLevel: Event level, must be the value in EventLevel enumeration
Type: Abnormal type, using a fully qualified name
INMESSAGE1: Abnormal Original Information Keyword 1
INMESSAGE2: Abnormal Original Information Keyword 2
INMESSAGE3: Abnormal Original Information Keyword 3
INMESSAGE4: Abnormal Original Information Keyword 4
Outmessage: Executive administrator defines user prompt information
Helplink: Executive Administrator Defining Help Link In this place, it may feel that the above data structure design does not reflect the requirements of hierarchical, here, my hierarchical design is like this: error analysis and matching dependence in ExceptionDetail The current thread language-related recorded type and inMessage1, INMESSAGE2, INMESSAGE3, INMESSAGE4 are determined, where Type is an abnormal type, using a fully qualified name, INMESSAGE1 ~ 4 is keywords in the error message.
The above five matching conditions constitute a hierarchical relationship:
Type.inMessage1.inMessage2.inMessage3.inMessage4;
This may be a bit less uncomfortable, but there is a benefit, that is, flexible. When the client's system administrator wants to define a new exception match record type.Message1.Message2.Message3.Message4, he does not need to define from the top layer, but only needs to define this one, so After weighing, this data structure is decided to bring the greatest convenience to each household.
There is also a data set to define the structure of the exception log. When an exception occurs, the structure is recorded in the log:
Let's explain the field:
GUID: full sentence unique identifier PK
EventLevel: Abnormal grade, is the value in EventLevel enumeration
Logtime: Expected time
ExceptionType: Abnormal type
ExceptiomoriginalMessage: Abnormal original information
ExceptionSource: An exception occurs or objects
ExceptionStackTrace: Exception Stack
ExceptionTargetsite: Method for causing exceptions
ExceptionHelplink: Excetion Help Link
CustomMessage: Unusual administrator defined information
CustomHelpLink: Executive administrator defined help link
UserName: System users who triggers anomalies
ExceptionInducedPath: Module path that occurs
These have formed the basic data structure of our exception publisher.
This exception publisher will use three files. The three files are in the same folder, which is the XML files of the above three datasets, and the location of the folder is specified in the application configuration file.
(Endlessly)
