Code Book 2 Reading Notes 03-Chapter 8 Defensive Programming

Chapter 8 Defensive Programming
Defense Programming
This concept comes from defensive driving. In defensive driving, you must establish such a thinking that you will never be sure what another driver will do. This ensures

You will not be hurt when others make dangerous actions.
The main idea of Defensive Programming: ChildProgramIt should not be damaged by passing in error data, even if there are error data generated by other subprograms.
8.1 protecting your program from invalid inputs
Protection programs against illegal data input
· Check all external data values
· Check the values of all input parameters of the subroutine
· Determine how to process incorrect input data

8.2 assertions
Assertions
Building your own assertion mechanic
Establish your own assertion Mechanism
Guidelines for using assertions
Guidance on using assertions
1. handle errorsCodeTo handle the expected situation, and Use assertions to handle the situation that should never happen.
There is a way for you to better understand assertions, that is, to regard assertions as executable annotations.
2. Avoid placing the code to be executed in assertions.
If you write the code into the assertions, When you disable the assertions function, the compiler may exclude the code.
3. Use assertions to annotate and verify the preconditions and postconditions conditions ).
4. For highly robust code, Use assertions before handling errors

8.3 error-handing Techniques
Error Handling Technology
1. returns the neutral value.
2. Use the next correct data
3. Return the same value as the previous one.
4. Use the closest legal value
5. Record the warning information to the log.
6. return an error code.
7. Call an error handling subroutine or object
8. An error message is displayed when an error occurs.
9. Use the most appropriate method for local processing
10. Close the program

Robustness vs. correctness
Robustness and correctness
Correctness means never returning inaccurate results, even if no results are returned, is better than returning inaccurate results. However, robustness means constantly trying to take some measures.

To ensure that the software can run continuously, even if some inaccurate results are made sometimes.

High-level design implications of Error Processing
Impact of high-level design on Error Handling Methods

8.4 exceptions
Exception
1. An error that cannot be ignored occurs when other parts of the exception notification program are used.
2. An exception is thrown only when the exception is true.
3. Do not shirk responsibility with exceptions
4. Avoid throwing exceptions in constructor and destructor unless you capture them in the same place.
5. Throw an exception at the appropriate abstraction level.
When you decide to pass an exception to the caller, make sure that the Abstraction Level of the exception is consistent with that of the subprogram interface.
6. Add all messages about the exception to the exception message.
7. Avoid using empty catch statements.
8. Understand the exceptions that may be thrown by the function library
9. Create a centralized exception reporting mechanism
10. Standardize the use of exceptions in the project.
11. Consider abnormal replacement solutions

8.5 barricade your program to contain the damage caused by errors
Isolate programs to tolerate the damage caused by errors
If some parts of the software process "non-clean" data and others process "clean" data, most Code does not have to be responsible for checking error data.
Converts the input data to an appropriate type.

Relationship between barricades and assertions
Relationship between barrier and assertion

8.6 debugging AIDS
Code for auxiliary debugging
Don't automatically apply production constraints to the development version
Do not automatically limit the product version to the development version.
Introduce debugging AIDS early
Introduce code for auxiliary debugging as soon as possible
Use offensive Programming
Attack-based programming
The exception should be handled in this way: Display it in the development phase, and enable self-recovery when the product code is running. ---- "Attack-style editing

(Offensive programming )"
Plan to remove debugging AIDS
Plan to remove debugging rich code
1. Use version control tools like ant and make and
2. Use the built-in pre-processor
3. Write your own Preprocessor
4. Use a debug stub

8.7 determining how much Defensive Programming to leave in production code
Determine how much defensive code should be retained in the product code
1. Keep the code that checks for important errors
2. Remove the code that checks for minor errors
3. Remove the code that can cause the program to crash.
4. Keep the code that can safely crash the program
5. Record error information for your technical support staff
6. confirm that the error messages left in the Code are friendly.

8.8 being defensive about Defensive Programming
Defense posture for Defensive Programming
Excessive Defensive Programming can also cause problems. If you use every method you can think of to check the data from the input and output parameters, your programmer will

It becomes bloated and slow.

Key Points
1. The error handling method in the final product code is much more complicated than "garbage in, garbage out.
2. Defensive Programming Technology makes it easier to discover and modify errors, and reduces the damage caused by errors to product code.
3. assertions can help people discover errors as early as possible, especially in large systems and highly reliable systems, as well as rapidly changing code.
4. The decision on how to handle error input is a key error handling decision and a key high-level design decision.
5. Exception provides an error handling method that is different from the normal process of the Code. If you pay attention to usage exceptions, it can be a useful supplement to the programmer knowledge toolbox.

At the same time, we should make a trade-off between exceptions and other error handling methods.
6. Restrictions on Product Code do not apply to software in development. You can use this advantage to add code that helps you troubleshoot errors more quickly in development.