Exception design guidelines, refer to Microsoft msdn, combine your own understanding and the handling of exception errors in past development, summarize the software development architecture, and how to better design A set of exception error guidelines.
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.
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.
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. Reference example from http://blog.csdn.net/troubleshooter/article/details/18401491
Code:
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 this way After separation, DoProcess() will not throw an exception!
if(DoCheck()==true)//这是Tester:状态监测
DoProcess();Common exceptions and handling methods in software development (own summary)
1 It is recommended to wrap the operation interface exposed by the UI layer with 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 are 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: displays the correct data, and writes the illegal data 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 you check whether 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 the detailed content of .NET Framework-detailed explanation of exception design principles. For more information, please follow other related articles on the PHP Chinese website!
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
