A negative case of contract thinking

I just published the article "What is contract" and suddenly found that I was writing theory in all of my articles, without examples to prove it. Therefore, we need to add a negative case-C ++ iostream. The opposite is true, not because the iostream library is not well designed (on the contrary, it is difficult for you to find a C ++ library that is more brilliant than the iostream design, in the ideological system without the concept of contract, component design will pay much price for handling errors with unclear rights and responsibilities.

As you know, the C ++ iostream library is very classic and first originated from the Bjarne stroustrup stream library. Later, it was improved by Jerry Schwartz, Martin Carroll, and Andy Koenig to become an iostream library, it has been incorporated into the usd c ++ Library released by the Bell lab and is widely spread. Later, the USD Library gradually disappeared, while iostream was spared due to its wide application and was placed in the standard library in a new form.

For error handling, when the iostream library was born (about 1985-1987), there was no exception Mechanism in C ++. Therefore, Jerry Schwartz invented such an error handling mechanism:

Example 1: Typical iostream error handling:

Ifstream ifs ("filename.txt", IOS: In );
If (! IFS) {// here the transformation to void * is implemented
// An error occurred while opening the file.
}

First, test whether the file is opened and then perform specific operations. This is a classic iostream library usage (idiom ).

We now imagine that the user does not perform this idiom well:

Int val;
Ifstream ifs ("filename.txt", IOS: In );
Ifs> val;

What happens if filename.txt fails to be opened?

If you still have Borland C ++ 3.1 of that year, try to test it. I guess nothing happens, or the program is in an extremely dangerous "undefined behavior" state.

This situation is unacceptable for C ++ database developers. Therefore, although the problem occurs due to user errors (they do not correctly test the stream status), the rights and responsibilities under the non-contractual ideology are unclear, iostream library developers are pursuing component development technologies that are sufficient to cope with user errors. As a result, iostream is dragged into the quagmire of complexity in one direction.

Let's take a look at the methods used in the standard library to deal with this situation. Standard iostream has a member function called exceptions (), which helps programmers switch abnormal modes. By default, the exception trigger is not enabled, so the situation is the same as that of the classic iostream library. If you call the following before operating iostream:

STRM. Exceptions (STD: IOS: eofbit | STD: IOS: failbit |
STD: IOS: badbit );
When the stream is not in good state, an exception will be thrown when an operation such as STRM> val; is executed.

This looks good, right?

I don't think so. Please forgive me for my objection to the C ++ standard. This is my first formal objection to the design in the C ++ standard.

The disadvantages brought by this design are complex first. In the C ++ standard library of Nicola josutis, I used five pages to explain this mechanism. Complicated design will inevitably lead to complicated rules for use. In the face of complicated rules for use, users can vote, that is, you do what you do, and I don't need it! Who read this post used exceptions () in the actual project ()? In fact, I am personally afraid of exception rather than undefined behavior.

For users, you don't need to use it, but you have to pay for its running performance and space. If you are interested, you may wish to track the implementation of an iostream function to see how much effort the iostream Library Design has consumed to support this exception, and how much clock your CPU has consumed.

The second drawback is the exception itself-even if you catch the exception, what should you do? The program may have completely left the execution environment when an exception occurs. Maybe you don't know why the exception occurs. What should you do? This is nothing more than notifying the user: "I am finished, because an exception occurred at XXXXXXXX. If you want to report it, send me an email ." Yes. What else can you do?

We try to analyze this situation from the perspective of contract. If we say "test first and then use" is traditionally an idiom, then we will rise to a contract in the contract idea. For C ++, the "stream in good state" should be used as a contract and checked in every member function. You can even set a debugging period flag to check whether the user has checked the overcurrent status. Before necessary operations are performed, You can first use assertions to check whether the user has checked the over-current status and met the contract. In this way, under the contract, users will be forced to use components in the correct way, thus greatly simplifying the complexity of component development.

Consider exceptions. If an exception occurs, the Retry Mechanism is provided in Eiffel. Bjarne stroustrup said that retry can do this, but it is often meaningless. Why is it meaningless? Because c ++ does not have the idea of contract, exceptions may be a programmer's bug. In this case, the results are the same no matter how many retries. However, the situation is different in Eifel. If all parties follow the contract well, when an exception occurs, we can say with confidence that this may be caused by a very accidental event. For example, in the network environment, another user suddenly performed an operation on the file or an accidental hardware exception at that moment. In this case, "try again" is a reasonable choice. We are likely to put exceptions in the cradle, so as not to have any impact on upper-layer modules.

Who said the idea of contract is not great?