. Net exception system implementation (1 description)

EASSystem exception subsystem (Problem description)

I. Purpose of using an abnormal system:

1. Hide the error information to prevent the error description at the code level from being exposed to the user.

2. Enhance system robustness to prevent module and system crash caused by local errors.

3. Facilitate debugging after deployment, record exception information to files and databases, and give feedback or perform centralized processing on a regular basis.

Ii. Common exceptions:

1. Careless consideration during programming is not weekly and incomplete during testing.

2. The order of function calls and the Object Reference caused by the call method are empty.

3. The resource is invalid. For example, the database connection is abnormal and the file does not exist.

4. Call C # system functions to generate exceptions from third-party code.

5. System exception (C # defined runtime exception ).

Iii. troubleshooting methods:

1. Perform unit tests to find the location where exceptions are caught due to omissions.

2. Use Try-Parse and Test-Do at the code level to minimize exceptions.

3. encapsulate system exceptions and C # class library exceptions and use your own exception system.

4. As long as the underlying functions involve resource usage, evaluate the method of generating exceptions and describe the exceptions in detail.

Iv. Exception Handling status in the EAS system

1. Client-layer exception handling is basically implemented (scattered and not uniform), most of which are related to verification. Common layer issues are caught at this layer, and most of them are captured using Common capture to display captured information, the specific exception type is unclear.

2. Exception Handling is basically not used in the Common layer, and the location of exceptions is chaotic. Exceptions are caught in the underlying code, exceptions are caught in the intermediate call process, and exceptions are nested in layers, which leads to inconsistent exception handling.

3. The exception record is incomplete. Record methods are worth discussing.

4. Exceptions caused by security control.

5. Exception records are not clearly defined by the log system, and how to handle the coincidence.

6. Protection of exception information.

V. Exception Handling System Framework in the EAS system:

1. Description:

1) encode the module to facilitate classification and exception handling.

2) encode all types of modules in layer-3 classes and class functions.

3) DAO (Data Access Object) captures, encapsulates, and adds module information for database queries.

4) The control class Object captures exceptions in detail, Encapsulating System, C # class library, and other class exceptions.

5) the boundary class (form object) is used to capture exceptions encapsulated by control functions. In a friendly manner, the exception is displayed (only exceptions that cannot be ignored are displayed ).

6) Some exceptions must be rolled back or re-executed.

2. Abnormal System Structure

1) domain model:

　　　　　　

2) exception capture and handling process:

 

3) convergence with the log system.

 

Vi. Issues arising from the Exception Handling System:

1. The Coding System of modules, classes, and functions is huge and requires document support (whether to implement or not)

2. Code addition has a wide impact. whether exceptions should be captured for function granularity requires further refinement.

3. The log system must be executed at the same time.

4. the prompt information at the Client layer should be detailed and unified in various modules.

5. The specific implementation should be weighed in terms of time, efficiency, and performance.

VII. Summary

The EAS exception handling system must be implemented before deployment to solve program stability, debugability, and other problems. The solution has been initially formed. After the project team discussions, we will continue to deepen the solution and make further corrections during the code implementation process.