C ++ history-exception

1. Purpose of exception

 

In the design and evolution of the c ++ language, Bjarne Stroustrup said that the design assumptions for exceptions are as follows:

1. Basically to handle errors

2. Compared with function definitions, exception handling is rare.

3. Compared with function calls, exceptions occur less frequently.

4. Exception is just a concept at the language level.

At the same time:

1. Exception is not used as another response mechanism, but a fault tolerance mechanism.

2. Instead of converting functions into a fault-tolerant question, it is intended to serve as a mechanism for Fault-Tolerant subsystems, even if each function is not concerned with global error handling in writing.

3. It is not intended to constrain all designers to a correct error handling concept, but to make the language more expressive.

 

Therefore, exceptions are actually the first to appear. I think it is more c ++'s supplement to a fault tolerance mechanism of c, rather than the improvement of the return value. Many books now advocate replacing the return value with the exception mechanism, claims that the exception mechanism has many advantages, and many people despise the exception mechanism. For example, the author of zero mq once said that the exception mechanism cannot be coupled with the cause of errors, I think they all understand the purpose of the exception mechanism.

 

2. Differences between an exception and a returned value (I understand it myself)

As a fault tolerance mechanism, exceptions do not want to replace the improvement of the return value check error. One of the most significant difference is that the return value does not cause program crash even if it is not handled, that is, the default semantics of the returned value is:

1. An error occurs in my function.

2. Even if an error occurs, you can ignore it.

The semantics of the exception mechanism is:

1. If an error occurs, you must handle the error. Otherwise, the program will crash.

 

The exception mechanism forces you to handle some things,You must be clear that I have encountered an error in this function and I have handled it,

The returned value is not mandatory.

 

So I suggest you consider when writing c ++ code. If an error occurs in this function, can I allow some programs to continue ?? Then decide whether to use exceptions or return values. The above is just my personal suggestion, not bjarne stroustrup's suggestion.

 

3. Why c ++ does not let users know what exceptions the function will cause?

Since the syntax of the exception mechanism is that if an error occurs, you must handle this error. However, in the declaration of the function, it is hard to see whether the function needs to capture exceptions. Therefore, the earliest c ++ design team had the idea of adding the exception thrown semantics to the function declaration.

Void function (int args) throw e1, e2

In this way, when you see this function declaration, you will know what exceptions this function will throw. In fact, I think this is quite convenient, now I don't know what exceptions internal programs will throw, which has been a problem for me. If so, we can know how many uncaptured exceptions our programs have during compilation.

If c ++ implements a static check of exceptions, we can directly detect errors in the code during compilation. What problems will happen ??

 

Suppose we have three functions, three of which have different modules,

Fun1 0 calls function1 and function1 calls function2. function2 throws an exception e1 and requires function0 to handle it. function1 and function0 must capture the function and throw it again to avoid compilation errors, function0 must handle this exception.

Later, function2 adds an exception to throw e2. In order to compile the code, we need to re-modify the code of function1 and re-compile function1. This modification will also affect function0, therefore, we must modify function0, which will lead to unnecessary code modifications and re-compilation. This is not what the c ++ design team wants to see.

 

Therefore, bjarne stroustrup thinks that such a static check is not expected by c ++. He thinks that this check will be better performed by another tool.

 

I am thinking that this syntax is not a kind of prompt syntax. It is only used as a prompt, and the compiler will not guarantee it. But let's look back. What is the difference between this and annotation ??

 

4: the Core of exceptions is resource management.

There is another headache in the exception: resource management. bjarne stroustrup also clearly states that the core of the exception design is actually resource management, because if a program opens a file, the program throws an exception during running, while the code for closing the file is after the program throws the Exception Code, the file cannot be closed normally.

 

At this time, RAII was born. I am also surprised to see that RAII was born due to exceptions.

 

Therefore, no matter whether the file is closed or not, as long as the function is parsed, our files can always be closed normally.

 

Bjarne stroustrup also proposes exception handling to the constructor to provide a direct method for reporting errors. If there is no exception function, we can only check whether the function has been constructed, on the contrary, scotter meyers or huter (forgot who it is, it is a great c ++) recommends that you do not throw an exception in the constructor, if an exception is thrown in the constructor, the requested resource may be leaked, for example

X = new X ()

If an exception is thrown during the construction of x, you will not be able to delete the resources applied for by new X. This is also an example of a c ++ exception that many people laugh.

As a result, many programs define another init for external calls. This is also the advice I often see on the Internet, so you often see the following code:

X = new X ()

Try

{

X-> init ();

}

Catch (...)

{

}

 

But bjarne stroustrup does not approve of this approach (http://www.cise.ufl.edu /~ Manuel/stroustrup/exists),

Having a separate init () function is an opportunity
-Forget to call init ()
-Call init () twice
-Forget to test that init () succeeded
-Forget that init () might throw an exception
-Use an object before calling init ()

In this regard, scotter meyers provides suggestions in item 10 of his more efficient c ++. In general, it is still necessary to observe that exceptions should not be thrown out in the constructor, instead, you can handle exceptions in the constructor and use RAII In the constructor to automatically manage resources. Of course, the next one is not necessary, as long as you can ensure that you can release resources normally, RAII is just for convenience.

 

5. Why can't I continue execution from where an exception occurs?

I think this is a feature that many people always wanted. At that time, the c ++ discussion group discussed this question for a long time. Finally, from the perspective of previous design, this so-called wake-up mechanism is unreliable, so it was not added. One OS was first designed in this direction. Later, almost all the wake-up functions were removed, I would like to estimate that the c ++ committee will not be added to this function based on such considerations.

 

The above is about some ideas about the design of the c ++ exception mechanism. Of course, some of my views are mixed here. In fact, from here, many people do not like c ++ because he does not understand the characteristics of c ++. Maybe he does not know the usage of c ++ is actually incorrect, it's just that c ++ hasn't disabled you.

 

I have recently read <C ++'s history and evolution> and I think it is quite interesting. Knowing the history of c ++, we know how many incorrect c ++ examples we have used in the past.

We also recommend bjarne stroustrup's article Standard-Library Exception Safety.

Http://www.cise.ufl.edu /~ Manuel/stroustrup/exists