Use of assertions in iOS development-NSAssert (), iosnsassert

Use of assertions in iOS development-NSAssert (), iosnsassert

 

Link: http://blog.csdn.net/univcore/article/details/16859263

Assertion refers to the code used during development that enables the program to perform self-check during runtime (usually a sub-program or macro ). If the assertions are true, the program runs normally. If the assertions are false, it means that unexpected errors have been found in the Code. Assertions are especially useful for large complex programs or programs with extremely high reliability requirements.

For more information about assertions, we recommend that you go to the defense programming chapter in code Daquan 2. Next, we will extract some classic guidance suggestions on the use of assertions in the code book:

Use assertions for reliable data from internal systems, rather than for externally unreliable data. Use error processing code for externally unreliable data. Assertions can be seen as executable comments.

Data outside the system (user input, file, network read, etc.) is untrusted and must be strictly checked (usually error processing) before being released to the system. This is equivalent to a guard. For internal system interactions (such as subprogram calls), if the input data is processed each time, the system does not have a trusted boundary and the code becomes bloated and complicated; in fact, in the system, it is the caller's responsibility to pass the expected appropriate data to the subroutine, And the caller in the system should ensure that the data transmitted to the subroutine can work properly. In this way, the unreliable external environment and reliable internal system environment are isolated to reduce complexity.

However, in the development phase, the code is very likely to contain defects. It may be because the program processing external data has not been fully considered. It may be because the code of calling the internal subroutine of the system has an error, causing the subroutine to fail to be called. At this time, assertions can be used to determine whether a subprogram fails to be called due to a problem. After all the defects are cleared, the internal and external credit systems are established. These assertions should not be necessary until the release.

 

In iOS development, macro NSAssert () can be used to process assertions in the program. Using NSAssert () correctly helps developers locate bugs as soon as possible. Developers do not need to perform assertion checks in each version of the application, because most projects have two versions: Debug and Release. In the Debug version, developers want all assertions to be checked, while in the Release version, assertions are often disabled. To disable assertions in the Release version, follow these steps:

In the Build Settings menu, find the Preprocessor Macros item. Under the Preprocessor Macros item, there is a selection for Program Generation configuration: Debug and Release. Select the Release item and set NS_BLOCK_ASSERTIONS. No asserted check is performed. As shown in.

Next, we add assertions in a function that prints the name to make the program throw an exception when it finds that the input name is null.

 

[Objc]View plain copy print?

1. -(Void) printMyName :( NSString *) myName
2. {
3. NSAssert (myName! = Nil, @ "name cannot be blank! ");
4. NSLog (@ "My name is % @.", myName );
5. }

When the parameter (myName) passed to the function is null, the asserted will be executed, the program Crash will be executed, and the description information in the asserted will be printed. In this example, the following logs are printed on the console:

 

 

NSAssert [1268: a0b] *** Assertion failure in-[ViewController printMyName:]

NSAssert/ViewController. m: 38

13:56:01. 927 NSAssert [1268: a0b] *** Terminating app due to uncaught exception 'nsinternalinconsistencyexception', reason :'The name cannot be blank!'

The assertion tells us that the input parameter cannot be blank. With this error, you can easily determine the cause and location of the error.

If we pass in a non-null parameter, the program will correctly print the input name:

My name is UnivCore.

Next, we set the test program to the Release version. Based on the previous settings, the assertions will not be executed even if the input parameter is null. The method for setting the version to Release is as follows:

Choose Product> Scheme> Edit Scheme... (You can also press the shortcut key command + shift +,), select the Run item, and modify Build Configuration to Release on the Info panel to change the current generation Configuration to Release. Then, generate and run the program to generate the Release version program. Note: For Archive items, the default configuration is Release.

At this point, we run the program again and the program will print the following statement:

My name is (null ).

This indicates that the asserted code is not running.