Home > Backend Development > C#.Net Tutorial > Detailed introduction to exception design guidelines in .net and other architectures

Detailed introduction to exception design guidelines in .net and other architectures

黄舟
Release: 2017-03-04 10:38:30
Original
1759 people have browsed it

Frontline

Exception design guidelines, refer to Microsoft msdn, combine your own understanding and the handling of exception errors in past development, and summarize the software development architecture , how to better design a set of exception error criteria.

Introduction to guidelines

Execution failure concept

The meaning of execution failure: execution failure occurs whenever a member cannot do what it was designed to do (what the member name implies). For example, if the OpenFile method cannot return an opened file handle to the caller, it would be considered an execution failure.

Translation:

The meaning of operation failure: Whenever a member module cannot complete its expected task, it is said that an operation failure has occurred. For example, the OpenFile method cannot return a handle to the open file to the caller, which is an operation failure.

Handling Exceptions in the Framework

In the Framework, exceptions are used for all error conditions, including execution errors.

Translation:

In the framework, exceptions are used to handle all error conditions, including execution errors.

Summary Guidelines

Which methods should be prohibited when designing exceptions, which should be done without hesitation, and which should be considered, are listed in the table below.

Number Method How to do
1 Return error code Prohibited
2 Execution error, to Throws an exception; if OpenFile() does not return a file handle Recommendations
3 If the code becomes unsafe to continue execution, Consider whether to call System.Environment.FailFast to terminate the process or throw an exception. Consider
4 If possible, throw an exception at the normal control flow, see the analysis below Prohibition
5 The impact of throwing exceptions on performance. Consider
6 Incorporate exception handling part into the agreement Suggestions
7 Return exceptions as return values Prohibited
8 Use the exception generator method to avoid code bloat , use helper methods to create exceptions and properties. Consider
9 Throwing exceptions in exception filters. Disallowed
10 Explicitly throwing exceptions from finally blocks Forbidden

 
Explanation on Article 4:

In daily coding, consider the Tester-Doer pattern for members that may throw exceptions in common scenarios to avoid performance problems related to exceptions. The Tester-Doer pattern pides a call that might throw exceptions into two parts: a Tester and a Doer. The Tester performs a test for the state that can cause the Doer to throw an exception . The test is inserted just before the code that throws the exception, thereby guarding against the exception. Example code from //m.sbmmt.com/

Reference:

Tester and Doer perform their respective duties, perfectly reducing exception throwing and improving performance.
Doer: The above status monitoring is good before it can be processed by DoProcess(); if it is false, and if DoProcess() includes DoCheck() logic, an exception will be thrown, but after this separation, DoProcess( ) will not throw an exception!

if(DoCheck()==true)//这是Tester:状态监测
    DoProcess();
Copy after login

Common exceptions and handling methods in software development (own summary)

1 The operation interface exposed by the UI layer is recommended to be wrapped in a try{}catch{} block, write the thrown exception to disk in catch.

2 When a timer is used in the UI layer, after an exception occurs in the counter's callback function, the timer must be stopped to prevent the error log from being written to the file.

3 The bottom layer is not recommended to wrap the try{}catch{} block. It is recommended to use throw to throw an exception directly. Because the try{} and catch{} blocks are wrapped on the UI layer, there is no It is necessary to write in these layers.

4 throw will directly interrupt future operations and jump to the outer stack try{} and catch{}, that is, the UI layer. Taking advantage of this property, it is generally recommended that functions do not return error codes.

5 When processing batch-imported data, a local exception occurred. Excel imports personnel, equipment, plans, materials, processes, etc. If a certain row of data violates the rules, it is not recommended to throw an exception at this time, because once an exception is thrown, it means that the data in the following rows cannot be imported, and the data that has been imported becomes dirty data.
Generally, there are two approaches: illegal data appears in a certain row and is recorded in the log file. In the future, based on this file, it is found that the data has not been imported, and then this one can be processed separately; Before importing, check directly After checking whether the data in all rows is legal, import one by one. Otherwise, a prompt will pop up and no data will be written to the database. It is generally recommended to do the latter. This approach is called: Tester-Doer exception mode, which is also recommended by Microsoft.

6 When processing the kanban display data, a local exception occurred. This processing mode is different from 5. Generally, when an exception occurs at this time, the former method of 5 is often adopted: Display the correct data, and the illegal data is written to the log for review; but it is also possible , if the main data in the displayed interface does not exist, an exception will be thrown directly, written to the log, and solved through the log. Therefore, it should be processed according to the abnormality severity of the data.

7 Based on development documents, logs, and analysis, try to find the reason why a certain function is not implemented. First, keep the development documents and check whether the current user requirements are consistent with those in the development documents. If they are consistent, the role of the log will be displayed at this time. For example, a pie chart summarizing the completion of all processes within a week. If there is no process data, then the pie chart may not exist. During the development process, if it is checked, It does not mean that there is a process. If a process is not found, an exception may be thrown. If the process is written to the log, the reason will be found. Therefore, this type of problem should also be written to the log. Although it is not an error, it can be classified as an exception.

8 The function returns an object whose methods and properties are referenced by subsequent logic. This is inevitable! And the implementation of most functions depends on this. Because the returned object will be referenced later, It is recommended to do a null comparison. If it is null, should it be passed to the UI layer and a message prompt will pop up, or an exception will be thrown directly. The UI layer will write it to the log after processing, depending on the situation. Certainly.

The above is a detailed introduction to the Exception design guidelines in .net and other architectures. For more related content, please pay attention to the PHP Chinese website (m.sbmmt.com)!


Related labels:
source:php.cn
Statement of this Website
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Popular Tutorials
More>
Latest Downloads
More>
Web Effects
Website Source Code
Website Materials
Front End Template