Three Realms of C ++ exception handling programming

This is what we thought after reading herb Sutter's "exceptional C ++" last time, because I was too lazy to update my blog and never wrote it down.
Generally speaking of three realms, many people will think of it ...... #1 see the mountains, see the water #2 see the mountains is not the mountains, see the water is not the water #3 see the mountains or mountains, see the water or water. Well, that's right. It's just about programming, C ++, and exceptions.

The reason is that after the end of work today, the boss went off work with his cell phone ringtone "on the beach. He left the district and brother Liang in the office. At that time, he seemed to be performing reverse engineering on an RDI program, while the district was just playing with Oberon.

"What is the most important paradigm for program exception security with C ++? How can I use try, catch, and finally ?" Liang suddenly asked.

Honestly, Niu x rarely asks questions below (although this question has a strong discussion meaning, the district right should be "consulted ), so I think it should be better.

"It is best to write a C ++ program with exceptional security. Do not use try, catch, and finally ." -- The answer is as follows.

"Oh, it's strange. How can this problem be solved ?" ---- You will be asked ~~

So the area says:
There are three levels of exception-related C ++ programming:

# The first realm is: the program does not see try, catch, finally.
This is a beginner's level. He does not know that some modules/functions will throw exceptions. If it is not processed, the program will crash and many resources will not be properly recycled in time. Or when he writes a program, he repeatedly applies errno or checks the return value to handle exceptions. The error code and the normal process code are stirred up, which is messy.

# The second realm is: there are many try, catch, and finally entries in the program.
This is an entry level. He knows how to handle errors by throwing exceptions. Therefore, in the program, the normal process will be unified in try, and all kinds of error handling will be placed in catch, carefully deal with the aftermath. Sometimes, catch (...) is used to forcibly press all exceptions. So there is no confusion? It's strange that although all kinds of aftercare are done, he doesn't know how many try and catch to write, and he often needs to put his ideas into catch.

# The third realm is: The program still does not see try, catch, finally.
However, the difference is that he is a master without a sword in his hands.
He knows the three guarantees of exceptional security, and knows when to provide the # resource recovery guarantee # data consistency guarantee # No exception guarantee.
--- He will use C ++'s powerful raiI (resource acquisition is initialization) to automatically Recycle resources when exceptions occur (a class can be written to manage a resource once and for all, you do not need to catch every day ).
--- He will use the pimpl technique (I like it) to help implement raiI and distribute logical operations to members to maintain consistency in case of exceptions.
--- In addition, he often uses a no throw swap operation to complete all operations at one time. In this way, the object will not become an unfinished building.
Therefore, this highly handwritten class does not need exceptions to disturb you. If exceptions occur in other internal classes, this exception is also safely passed to the previous level through this master class, the data integrity of the class is not damaged. Although exceptions still exist, they are safe ~

Therefore, it is better to write a module with exceptional security ~ ::
Exception (it will occur), raiI, pimpl, data consistency, swap.
If you forget it, you can go through the boost: shared_ptr source program. (In fact, I did not dare to say this to my brother)

In fact, try catch is a relative concept. When you know that a module reports an error by throwing an exception and the responsibility for handling this error is the module caller, you should use try instead of leaking the exception. For example, boost: lexical_cast user ~

For example, the beam module is generally released in the form of a C function interface. It is also appropriate to add a try at the top of the module.

Liang himself also said that the program that is currently being reversed uses a good Seh (this is a Windows exception handling function), so it is easy to grasp the developer's intention-you see, it is better to write programs with exception processing, and the readability of disassembly is much stronger than that of the error code returned (of course, some do not want to be reversed ).