How to reasonably create bugs in iOS development

[[163210]]

What is a BUG? To put it simply, the program does not run as we expected. I prefer to divide BUG into two categories:

1. Crash
2. No crash

In the usual programming practice, we may simply equate BUG with Crash. And we also put a lot of energy on solving Crash bugs. But we don't seem to pay much attention to BUGs that don't crash. However, in reality, those heart-wrenching "pitfalls" are often caused by BUGs that don't crash, such as the OpenSSL heart bleed a while ago. Why do I say that? Let me explain it slowly.

How to create BUG reasonably

A crashed BUG proves that there is a problem with your program by the program's death, and you must hurry up to solve the problem. A bug that does not crash is like a liar who pretends to be able to operate normally, making the entire program run in an unstable state. Although it looks good on the outside (no crash), the inside is already rotten. Once the problem is revealed, it is often fatal, such as OpenSSL's heart bleeding. This is what the predecessors have summarized: "Dead programs don't lie."

Crash is not scary. What is scary is that the program does not crash but runs in an unstable state. If the program also operates data, the harm it brings will be catastrophic.

So feel free to let the program crash, because when it crashes, you still have a chance to fix your mistakes. If it doesn't crash, then the entire program and product may have to be destroyed. Therefore, one of the principles of creating "bugs" reasonably, and also the most important principle, is to create as many bugs as possible that cause crashes, reduce the number of bugs that don't crash, and if possible, convert bugs that don't crash into bugs that cause crashes for easier searching.

NSAssert

This should be familiar to everyone. Its name is "assertion". Assertion refers to the code (usually a subroutine or macro) used during development to allow the program to self-check at runtime. If the assertion is true, it means that the program is running normally, and if the assertion is false, it means that it has found an unexpected error in the code. Assertions are especially useful for large and complex programs or programs with extremely high reliability requirements. When the assertion is false, the processing strategy of almost all systems is to let the program die, that is, crash. It is convenient for you to know that there is a problem with the program.

Assertions are actually a common method of "defensive programming". The main idea of ​​defensive programming is that a subroutine should not be destroyed by the input of erroneous data, even if the erroneous data is generated by other subroutines. This idea is to control the impact of possible errors within a limited range. Assertions can effectively ensure the correctness of data and prevent the entire program from running in an unstable state due to dirty data.

For more information on how to use assertions, please refer to the chapter "Defensive Programming" in Code Complete 2. Here is a brief excerpt to summarize the main idea:

1. Use error handling code for situations that are expected to occur, and use assertions for situations that should never occur.
2. Avoid putting code that needs to be executed in assertions
3. Annotate and verify pre- and post-conditions with assertions
4. For highly robust code, assertions should be used before error handling.
5. Use assertions for reliable data from internal systems, and do not use assertions for external unreliable data. For external unreliable data, error handling code should be used. In iOS programming, we can use NSAssert to handle assertions. For example:

 - ( void )printMyName:(NSString *)myName
 {
 NSAssert(myName == nil, @ "The name cannot be empty!" );
    NSLog(@ "My name is %@." ,myName);
 }

We verify the security of myName and need to ensure that it cannot be empty. NSAssert will check the value of the expression inside it. If it is false, the program will continue to execute. If it is not false, the program will crash.

Each thread has its own assertion handler (an instance of NSAssertionHanlder). When an assertion occurs, the handler prints the assertion information and the current class name, method name, and other information. Then it throws an NSInternalInconsistencyException to crash the entire program. And in the assertion handler of the current thread, handleFailureInMethod:object:file:lineNumber:description: is executed with the above information as output.

At that time, when the program was released, the assertion could not be included in the installation package, because you didn't want the program to crash on the user's machine. To turn on and off the assertion, you can set assert in the project settings. After setting NS_BLOCK_ASSERTIONS in the release version, the assertion is invalid.

Avoid using Try-Catch if possible

It's not that the exception handling mechanism like Try-Catch is bad. But many people use Try-Catch incorrectly in programming, and use the exception handling mechanism in the core logic. They use it as a variant of GOTO. They write a lot of logic in Catch. I would like to say, why not use ifelse in this case?

In reality, exception handling is just a way for users to handle exceptions in software. A common situation is that a subroutine throws an error to let the upper-level caller know that an error has occurred in the subroutine and let the caller use an appropriate strategy to handle the exception. In general, the strategy for handling exceptions is to crash the program, causing it to die and printing out the stack information.

In iOS programming, errors are thrown in a more direct way. If the upper layer needs to know the error information, a pointer to a pointer to NSError is passed in:

 - ( void ) doSomething:(NSError* __autoreleasing*)error
 {
 ...
 if (error != NULL)
 {
        *error = [NSError new ];
 }
 ....
 }

There are very few scenarios that can be left for exception handling, so try not to use Try-Catch in IOS programming.

(PS: I have seen designs that use Try-Catch to prevent program crashes. If you don’t have to, try not to use this strategy.)

Try to crash the bugs that have not crashed yet.

The above mainly talks about how to find the "bug" that crashes. Another way to reasonably create "bugs" is to try to crash the "bugs" that have not crashed. There is no more reliable method for this, just rely on brute force. For example, write some array out-of-bounds and so on. For example, for those difficult multi-threaded bugs, find a way to make them crash, and it will be easier to find them after they crash.

In short, program with the mentality of letting the program "die" and live towards death.

How to find bugs

Actually, the term "finding bugs" is a bit unreliable. Because bugs never need you to find them, they are there, and they only increase. Bugs always come to you, and you rarely take the initiative to find bugs. The program crashes, and then we have to work overtime. In fact, we are looking for the cause of the bug. Find the culprit that caused the bug. To put it more theoretically: among a bunch of possible causes, find those that are causal with the bug (note, causality, not correlation).

Therefore, solving BUG can generally be divided into two steps:

1. Make a reasonable assumption and find the most likely series of causes.
2. Analyze the causality between the cause found above and the BUG. It must be determined that the BUG is caused by a certain cause and only by this cause. That is, it is determined that a specific cause is a necessary and sufficient condition for the BUG. After finding the cause, the rest is relatively simple, and the code is changed to solve it.

Reasonable assumption

In fact, the causes of BUG can be divided into two categories:

1. A problem with our own program.
2. System environment, including OS, library, framework, etc. If we find the former, we can fix it. The latter is more helpless. We can either complain or email the developer. It is unknown whether it can be fixed in the end. For example, when making a framework for IOS, the category will report an exception that the method cannot be found, and it has not been solved yet.

Of course, 99.999999% of the time, we are the ones who cause the program to go wrong. So let's assume the first reasonable assumption:

First doubt yourself and your program, then doubt everything

The problem with the program is actually the developer's own problem. After all, bugs are the programmer's children and grandchildren. We created bugs ourselves. There are three reasons why developers can create bugs:

Insufficient knowledge reserves. For example, the common null pointer problem in iOS is often caused by unfamiliarity with the memory management model of iOS.

Carelessness is a typical example of an array out-of-bounds error. Another example is not paying attention when converting types. For example, the following program:

 //array.count = 9  
 for ( int i = 100 ; array.count - (unsigned int )i > 10 ; )
 {
 i++
 .....
 }

Logically, this should be a program that can be executed normally, but when you run it, it is in an infinite loop. You may have tried many days to fix the infinite loop problem but still can't solve it. It was not until your colleague told you that array.count returns NSUInterge, and when it is used with unsigned integers, if a negative value appears, it will be out of bounds. Then you suddenly realized: Damn, it's a type problem.

Logical Error

This is a problem of thinking mode, but it is also the most serious problem. Once it happens, it is difficult to find. People always have the hardest time doubting their own thinking mode. For example, the problem of infinite loop, the most serious one is the circular reference between functions, and the problem of multithreading. But fortunately, most of the bugs are caused by insufficient knowledge and carelessness. So the second rationality assumption:

First, we should suspect the basic reasons, such as human factors such as our own knowledge reserve and carelessness, and then find specific problems through these reasons. Then we can suspect the difficult logical errors. With the above basic strategies for reasonable suspicion, we can also not lack some basic materials. That is, the common reasons for crashes. In the end, we still have to land on these specific reasons or codes to find the causal relationship with the bug.

1. Accessing an object that has been released, such as: NSObject * aObj = [[NSObject alloc] init]; [aObj release]; NSLog(@"%@", aObj);
2. Accessing an array class object out of bounds or inserting a null object
3. A non-existent method was accessed
4. Byte alignment, (type conversion error)
5. Stack Overflow
6. Multithreaded concurrent operations
7. Repeating NSTimer

Reasonable assumption number three: Try to find possible specific reasons.

Causal Analysis

First of all, we must explain that we are looking for "causality" rather than "correlation". These are two extremely confused concepts. Moreover, many times we mistake correlation for causality. For example, when solving a multi-threaded problem, you found a data confusion problem, but you couldn't figure it out. Finally, one day you accidentally added a lock to an object, and the data became normal. Then you said that the problem was caused by the lack of shackles on this object.

However, based on your analysis above, you can only conclude that whether the object is locked or not is related to data anomalies, but cannot conclude that it is the cause of data anomalies. This is because you have not been able to prove that object locking is a necessary and sufficient condition for data anomalies, but only used a single dependent variable experiment, where the variable is the lock state, and the value is x=[0, 1], where x is an integer. Then the experimental results show that whether the object is locked or not is positively correlated with data anomalies.

Correlation: In probability theory and statistics, correlation (also called correlation coefficient or association coefficient) shows the strength and direction of the linear relationship between two random variables. In statistics, the meaning of correlation is to measure the distance between two variables relative to their independence. Under this broad definition, there are many coefficients defined according to the characteristics of the data to measure the correlation of data.

Causality: Causality is the relationship between one event (i.e., the "cause") and a second event (i.e., the "effect"), where the second event is considered to be the result of the first event. Mistakenly equating correlation with causality is a common logical error not only among programmers, but almost everyone. To deepen your understanding, you can read this short popular science article: Correlation ≠ Causality.

The first problem of causal analysis is not to be deceived by your own logical errors, and to correctly distinguish the difference between correlation and causation. Don't equate correlation with causation.

The next step is causal analysis. As I have said before, the purpose of causal analysis is to determine whether a specific cause is a necessary and sufficient condition for the occurrence of a bug. To determine this, two steps are required:

1. Proof of sufficiency
2. Proof of necessity

Regarding the proof of sufficiency, this is basically normal logical reasoning. The basic idea is to be able to restore the path where the bug occurs, from the cause to the code where the bug occurs, and what kind of function calls and control logic are taken. Once this is determined, the sufficiency can basically be proved. In general, based on the stack information of the crash, the sufficiency can be proved very directly.

Regarding the proof of necessity, this is more difficult. The definitions of sufficiency and necessity are as follows: when the proposition "if A then B" is true, A is called a sufficient condition for B, and B is called a necessary condition for A. Then the necessity is that the BUG can be the cause of the cause of the BUG. This statement is more difficult to understand. In other words, you have to confirm that this BUG can explain the cause, and this BUG is and only caused by this cause.

Only by proving the sufficiency and necessity can we truly find the cause of the BUG.