1, abnormal influence efficiency, should it be avoided? Indeed, full optimized unusual procedures, normal conditions should be more efficient than the procedures that use exception handling, but with the development of compilers and virtual machine technology, this gap is getting smaller and smaller. Especially for complicated application systems, there will be more efficient situations that use exceptions. Because you can manage the "abnormal situation", it is possible to avoid setting and constraints for each error. It is really worthy of our programming. It is the underlying system development and embedded system, which is still a stage of various compilation skills and micro-technical hegemony. This is also why the developer is allowed to set up exception support in the C standard. 2. Exception processing is added in all operational steps. This is another extreme. Experience tells us that extremes are often wrong. This time there is no exception. Abuse abnormalities, indeed seriously affecting the efficiency of the program. And the process of abnormal processing is different from the "normal" program flow, so excessive use of exceptions will cause the program to confuse. In case of excessive excessive procedures, the reader may feel back to the "Goto" ranking era. For advanced languages, the compiler will process the resources used inside the language. An exception usually only throws only when an error (system or business rules) occurs, and protection is performed when the external resource is called. The "external resources" here refers to the resources that the compilation system cannot be automatically managed. In different languages, there may be different meaning. For example, in the C # and Java language, due to the existence of the virtual machine, we can protect the resources of the I / O and databases without considering the application and release of the pointer. But in ISOC , we have to take into account the pointers that have occurred, the previous application, and how they are cited how they are released. For specific rules, we will discuss later. 3, what time is thrown out? In addition to hardware errors, and system failures caused by system failures (such as shortcomings, I / O Accessions, zero emissions, etc.), support exceptions also support custom exceptions. This is a very useful feature. This way we can put an error in the application system into anomalies. Of course, custom anomalies should be degrees, usually we will define errors that may endanger the application system as an exception, such as text encoding errors, potential attack behavior, SOAP interface passed the data format incorrectly, embedded script syntax errors (If the SQL script is wrong, this is usually thrown by Framework) and so on. But the user enters the error in such a problem, usually we do not perform an exception handling, but is considered part of the system and user interaction. 4. Can an abnormality replace some previous programming technologies? Yes, for example, in the form of ErrorCode Fun (Arg1, Arg2, ... out arg) in the Windows API; can no longer appear in newly written programs. We don't have to put the return value to the error code (it does not necessarily use it), and put the real return value in a reference parameter. It is now possible to make each of the parameters, when there is an error, you can do an exception object in the function body. It does not take up the normal business process, nor does it need our query manual to understand the meaning of the error code representative, and you can carry any information we need in the exception object. Of course, in the face of new situations, we have to have new initiatives, and we have to intercept and process in a timely manner.
5, when is it intercepted? Typically, we should do an abnormal protection in any place to call external resources to ensure that the resources apply normally (see Article 2), and in addition, in the business stream that requires atomic protection, it should be noticed. After interception is abnormal, it should not be easily masked, but appropriately for different exceptions. Unrelated to the current process should be thrown up again. Finally, in the main thread of the application system (program), a unified anomalous capture and processing system should be added, and the unprocessed exception should be recorded all. This protection code has been implemented for us in some Framework, and we have to write our exception handling code into the main thread error handling handle. Aiming for resources, there are several common examples as follows: For example, when we open a file, it is usually in Python: try: f = open ("filename") # Add to process code. Except oreror: # 加 加 错 错 处理 PASSFINALLY: F.Close () and in C # is try {using (filestream fs = system.IO.File.Open ("FileName", System.IO.FILEMODE.OPEN) {/ / Add Business Code}} Catch (ArgumentException) {// Add Parameter Abnormality} Catch (IOException) {// Add IO Excetion} Catch (Exception) {// Add other abnormal processing} The USING statement here is C # unique A resource protection mechanism similar to FINALLY, which guarantees the object constructed in () in the Using the code execution to call the IDispose interface (of course, this type implements idispose) Release its occupied resources, whether it is in Using An exception occurs. Similar to us can also handle in the FINALLY of the TRY statement. FileStream Fs;
Try {fs = system.io.file.open ("filename", system.io.filemode.open; // Add related code} Catch (argumentException) {// Add parameter exception handling} catch (ioException) {//// Add IO Exception Handling} Catch (Exception) {// Add other exception processing} Finally {if (fs! = Null) {fs.close ();}} The exception protection mechanism in C is special, it does not have a Finally keyword . According to the C designer's point of view, the program calls the destructor of the object constructed in the TRY code segment, and all resources that need to be protected should be packaged in the class and write its release code to the analyzable function. That is, the same code should be like this in C : first define a class:
Class Handlefile
{
Private:
// Define file stream objects
PUBLIC:
/ / Open the file in the constructor
Handlefile (std :: string filename)
{
//open a file
}
Void Run ()
{
// Join business code
}
~ Handlefile ()
{
// Release the file stream
}
}
When calling:
Handlefile * HF
Try
{
HF =
New Handlefile ("FileName");
HF-> Run ();
DELETE HF;
}
Catch (xxxexception e)
{
// Treatment exception
}
// ...
