Error handling specification
〇, concept clarification
Concept explanation error
It means: causing the system that cannot be worked in accordance with the user intention, the event does not mean: java.lang.Error and its subtype
Refers to: a specific programming language, an error performance mechanism provided by the development platform does not refer to, but includes: java.lang.Excetion, java.lang.exception and its subclasses, SYSTEM.EXCEPTION, STD :: EXCEPTION and their children
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.
According to the way, the usual classification is as follows:
Exhibition means involving module interface prompt
Only the indication layer needs to display the interface prompt indicator must capture all errors, avoid your own process or host process crash record log.
In addition to the "input verification module of human machine interaction", all modules outside "XXX Module" should record errors
Second, abnormal processing specification
in principle
Abnormal should be a hierarchical exception should be centralized
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 somexception ();
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 is very easy to attack
Error code and abnormal
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
Translator Note: When writing a program, if you do not use try-catch to capture exception or explicitly throw anomalies, you want the program to automatically throw, some language compilers do not allow compilation, such as Java. This is the most basic meaning of Checked Exceptions. The purpose of this feature is to ensure the security and robustness of the program. Zee & Snakey (MVP) There is a very image of this, you can see http://www.blogcn.com/user2/zee/main.asp. Bruce Eckel also has related articles: "Does Java Need Checked Exceptions", see http://www.mindview.net/etc/discussions/checkedExceptions
Reserve attitude toward checked exceptions
Bruce Eckelc # No Checked Exceptions, how did you decide whether this feature is placed in C #? Anders Hejlsberg I found Checked Exceptions There are more problematic issues in two aspects: scalability and version control. I know that some things about Checked Exceptions are also tend to be our view to this problem. Bruce Eckel I have always thought that Checked Exceptions is very important. Anders Hejlsberg is, honestly, it looks quite important, this view is not wrong. I also praised the wonderful checked Exceptions feature. But its implementation of some aspects will bring some problems. For example, from the implementation of Checked Exceptions in Java, I think it has a series of new problems while solving a series of problems. In this way, I can't figure out whether the Checked Exceptions feature can really make our lives more wonderful. There are different opinions on this. Bruce Eckelc # Design Team has a lot of debate on Checked Exceptions? Anders Hejlsberg is not, on this issue, we have a wide range of consensus. C # is currently kept skewer in Checked Exceptions. Once there is a well-recognized solution, we will reconsider and adopted in the appropriate place. I have a business creed, that is - if you don't have a say, there is no way to advance its solution, then it is best to keep silent and neutral, and should not put a rack of this. Suppose you let a novice to edit a calendar control, they usually think this: "Oh, I will write the best calendar control in the world! I want it to have a variety of calendar appearance. It has a display section, There is this, there is that ... "They put all these ideas into the control, then spent two days to write a very foot calendar program. They want: "In the next version of the program, I will implement more and better features." However, once they start thinking about how many abstract thoughts in my mind, they will find their original design. It is completely wrong. Now, they are suffering from a corner, they find that the original design must be abandoned. I didn't see it twice once. I am a minimum programist. For issues that affect global solutions, don't bring it into the entire frame before there is no practical solution, otherwise you will not know what this frame will become in the future. Bruce Eckel Extreme Programming, "" "" Anders Hejlsberg is: "Anders Hejlsberg is also said:" I will act as simply as possible. "I am most concerned about Checked ExcPetions What problems can it bring to programmers. Imagine, when the programmer calls some newly written APIs with their own specific exceptions, the program will become so messy and lengthy. At this time you will understand that Checked Excetion is not in helping the programmer, but it is in touch. The correct approach is that the API designer tells you how to deal with exceptions instead of let you want to break your head. CHECKED EXCEPTIONS version correlation
Bill Venners you mentioned two questions from the extensibility and version relevance of CHECKED Exceptions. Can I explain what they mean now? Anders Hejlsberg let me talk about version correlations, this problem is more likely to understand. Suppose I created a method foo and declare that it may throw out the A, B, and C. In the new version of Foo, I have to add some features, thereby impossible to throw an exception D. This will produce a very destructive change because it is almost impossible to handle D exception when this method is called. That is to say, when an abnormality thrown in the new version, the code to the user has brought destruction. There are similar problems when using methods in an interface. An interface that implements a particular function is released, it is not changeable, and new features can only be added in the new interface. In other words, it is only to create a new interface. In the new version, you only have two options, either build a new method foo2, FOO2 can throw more exception, or capture exception D in new FOO, and convert to the original exception A, B or C. Bill Venners But Even in languages without Checked Exceptions, (Add new exception) Does it also cause damage to the program? If the new version of FOO throws a new exception that requires users, is it only because the user does not want this anomalies, can he write a code when you write a code? Anders Hejlsberg is not, because in many cases, users don't care (abnormally). They don't deal with any exceptions. In fact, there is a final exception handler in the message loop, which will display a dialog prompt you to run an error. Programmers can use Try Finally to protect their code anywhere, and the program can still run correctly even if there is an abnormality at runtime. For the processing of an exception itself, in fact, the programmer is not concerned. Many language of Throws syntax (such as Java), there is no need to force you to deal with exception, that is, forced you to figure out every unusual source. They ask you either to capture the abnormality of the declaration, or put them in the throws statement. In order to achieve this request, the programmer has done a lot of ridiculous things. For example, when they declare each method, they must add a modifier: "Throws Exception". This is entirely on the slave of this feature, it is just that the programmer does more official articles, and there is no benefit of any benefits. Bill Venners, you think that the programmer does not require the programmer to deal with each unusual practice, in reality What do you want to apply? Why is Andrs Hejlsberg think that (explicit) exception is very important? This is so ridiculous. It is not important at all. In my impression, a very good program, the number of TRY Finally and TRY CATCH statements is approximately 10: 1. In C #, what is the BILL VENERSFINALLY? Anders Hejlsbergfinally guarantees that you are not abnormal, but it does not directly process exceptions. An exception handling should be placed elsewhere. In fact, in any event-driven (such as a modern graphical interface) program, there is a default anomalous process in the main message loop, and programmers only have to handle those who have not been default. But you must ensure that the original allocated resources can be destroyed in any abnormal situation. In this way, your program is sustainable. You must do not want to write a program, you have to deal with an exception and pop up the dialog box in 100 places.
If you do, you have to make your mildew when you modify it. Abnormal should be centrally processed and protect your code Checked Excetions extensibility in an exception.
What is the extensibility of CHECKED Exception? Bill Venners? Anders Hejlsberg scalability is sometimes related to version. In a small program, Checked Exceptions is very charming. Can you capture FileNotFoundException anomalies and display it, is it interesting? This is also very wonderful when calling a single API. But when developing a large system, the disaster is coming. You plan to include 4,5 subsystems, each subsystem throws 4 to 10 exceptions. But (when actually developed), you climb the first level on the ladder of the system, and the new exceptions that must be processed will grow index. Finally, 40 exceptions can be thrown each subsystem. When you integrate two subsystems, you will have to write 80 THROW statements. Finally, you may not be controlled. Many times, Checked Exceptions will irritate programmers, so programmers will find ways to bypass this feature. He is either all written "throws exception", or - I don't know how much I have seen - Write "TRY, DA Da Da Da Da (Translator Note: Meaning Flying a code), Catch Curly Curly (Translator Note: 即 '{}') ", then said:" Oh, I will turn back to handle these empty anomalous handling statements. "In fact, there is no one if anyone will go back to these things. At this time, Checked Excetion has caused a great drop in system quality. So, you may pay great attention to these issues, but when we decide whether to put some mechanisms of Checked Excetions in C #, it is quite a thing. Of course, know what exception may throw it in the program, there is still a considerable value, and some tools can also be checked in this regard. I don't think we can build a sufficiently strict and rigorous rule (to complete the abnormal check), because (abnormal) may be caused by the compiler's error. But I think I can analyze the tools in the (program) analysis tool, detect if there is a suspicious code, whether there is an unprepared anomaly, and give you these hidden vulnerabilities
