First, overall specification
According to the wrong type, the usual processing method is as follows:
Error type range processing mode Operator error does not satisfy the input rules, input range, etc. when the human-machine interface interacts
Check the user input prompts the correct rule to enforce the error that changes when the runtime error is incorrect with external resources, such as network, file system, database, other business application systems, etc.
Record and throw an exception, please see the "Exception Processing Specification" programmer error and the client module does not meet the error occurrence of the front condition of the back condition, if the library is called by other programmer, the parameters are out of the range, etc.
Use assertion
According to the type of call, the usual processing is as follows:
Call type processing mode Synchronous call
For an abnormality that is abnormal, captured and processed, the original information is too technically, captured and packaged, re-throwing the intermediate layer called, and keeps silent for unknown exceptions in the highest layer of call, must capture all exceptions, Avoid your own process or host process crash, please see "Abnormal Handling Specification" asynchronous calls.
Asynchronous calls generally should not have any return value server to return normal information and error information in the same manner, that is, the normal information is returned by the notification, the error message should also return by notification; normal information is by active If the query is obtained, the error message should also be obtained by active query.
Second, abnormal processing specification
Abnormalities should be hierarchical
Anomaly definition
Each module should have its own application exception type hierarchy, from this module, the application exception should belong to the exception type, customer code can only capture all customized class (?) Applications all customizable All abnormalities should run from the "Application Orthnosus" derived middleware and other platforms such as the "Application Abnormality" derived middleware of the development platform, should be run from the "runtime abnormality base class" (?) Middleware and other platforms. When the error should be derived from the "wrong base class" provided by the development platform (?)
Abnormal capture
For an abnormality that has the ability to process and handles and processes the intermediate layer that is called, the unknown exception is kept silent in the highest layer of the call, and all the exceptions must be captured, avoiding each of the original abnormal information captured by the process or host process crash record.
Abnormally thrown
Each module should use the most accurate error reason for this module to report an exception information If there is a primitive exception, an original exception is attached to the re-thrown exception.
Third, a few points
Error handling and log system
Error handling is not equivalent to the log system, the log system is only the error message of the error message, the output of the error message should all call the log system to complete
Programmer error and runtime error
The front condition of the interface function should be a specification, and the client programmer must comply with the agreement; the customer programmer violates the agreement, the program will produce an abnormal or unpredictable error; for such contributions, there should be no need to run Code check; such as if a parameter of your interface function cannot be NULL, and you write in some programs in the function:
IF (xxx == null) {
Throw new someexception ();
}
Your code actually allows the parameter to be null because you run the NULL's situation; although you declare that parameter in your document, you can't be null, but if the customer programmer complies with the agreement, then your check code Redundancy
When you don't check the parameters, the illegal parameter value causes an error, there are two cases: If you list the illegal values that the parameters are not allowed in the interface function description, then the customer programmer The program should be modified to avoid incoming illegal values, which is called programmers; if you do not explain, then you should modify the function and process illegal parameters.
Not all restrictions explain in the document, you can throw the responsibility to the customer programmer, there are some errors must be handled: especially the customer programmer does not need import your package to interact with your interface, such as Socket server, you must check all received data within the Socket service program, refuse the wrong request, otherwise it will be very easy to attack the error code and exception
You should not use the BOOL value to return success or no, the BOOL return value is applied only in the active operation of the Bool state, such as Bool IsDirty (), Bool Hasnext () and other shaping or BOOL type error code return value forced customer programmer checking Each call, the application is abnormally replaced
Four, appendix
Anders Hejlsberg talks about C # abnormal design
