Chapter 4 Preventive programming (Code Daquan 4)

8.4 exceptions

Exception

　　

An error that cannot be ignored occurs when other parts of the exception notification program are used.

An exception is thrown only when the exception is true.

Do not shirk responsibility with exceptions

Avoid throwing exceptions in constructor and destructor unless you capture them in the same place

Throw an exception at the appropriate Abstraction Level

Add all information about the exception to the exception message.

Avoid using empty catch statements

Understand the exceptions that may be thrown by the function library

Create a centralized exception reporting mechanism

Standardize abnormal use in projects

• For languages such as C ++ that can throw a variety of objects, data, and pointers, a standard should be set for the classes that can be thrown. To be compatible with other languages, you can consider throwing only the objects derived from the exception base class.
• Consider creating a specific exception class for the project. Used as the base class for all exceptions that may be thrown in the project. In this way, operations such as logging and reporting errors can be centralized and standardized.
• Specifies where the code is allowed to use the throw-catch statement to handle errors locally.
• Specifies where the code is allowed to throw exceptions that are not partially processed.
• Determine whether to use the centralized exception reporting mechanism.
• Specifies whether exceptions can be used in constructor and destructor.

Consider abnormal replacement solutions

Some programmers use exceptions to handle errors only because the programming languages they use provide this special error handling mechanism. You should consider various error handling mechanisms from beginning to end: you can use local processing errors, use error codes to pass errors, record debugging error messages in log files, disable the system, or use other methods.

Finally, please consider whether your program really needs to handle exceptions, rather than releasing all the resources that have been obtained and terminating program execution, so that the user can re-run the program with the correct input data.

8.5 barricade your program to contain the damage caused by errors

Isolate programs to tolerate the damage caused by errors

Barricade is a damage tolerance strategy ).

　　

Converts the input data to an appropriate type.

Relationship between barricade and assertions

Relationship between barrier and assertion

The use of the barrier clearly distinguishes assertion from error handling. The program application error handling technology outside the barrier bar, where any assumptions about data are insecure. The assertion technology should be used in the internal program of the barrier, because the imported data has been cleared when it passes through the barrier. If a subroutine inside the barrier detects the error data, it should be an error in the program rather than an error in the data.

The use of the barrier also shows the value of "specifying how to handle errors at the architectural level. It is required that the code inside and outside the barrier is a decision at the architectural level.

8.6 debugging AIDS

Code for auxiliary debugging

Don't automatically apply production constraints to the development version

Do not impose restrictions on the product version on the open version automatically

Some speed and resource usage should be sacrificed during development, in exchange for some built-in work that can make development smoother.

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. This is "attack-based programming ".

• Make sure that the asserted statement terminates the program.
• Fill in all the allocated memory, so that you can find out the memory allocation error.
• Make sure that the default branch or else branch in each case statement can produce serious errors (such as terminating the program ). Or at least these errors will not be ignored.
• Fill in junk data before deleting an object.
• Let the program send the error log file to you by email.In this way, you will be able to understand what errors have occurred in the released software-if this applies to the software you have developed.

Sometimes, the best defense is a bold attack. A painful failure in development will prevent you from losing your product after it is released.

Plan to remove debugging AIDS

Plan to remove debugging auxiliary code

　　Use the make tool in the version control tool box like ant and makeThe version control tool can compile different versions of programs from the same set of source code. In the development mode, you can let the make tool include all the debugging code and compile it together. In the product model, the make tool can exclude debugging code that you do not want to include in the commercial version.

　　Use built-in preprocessing

　　Write your own processor

　Use a debug stub

8.7 determing how much Defensive Programming to leave in production code

Determine how much defensive code should be retained in the product code

Code for checking important errors

Remove code that checks for minor errors

Remove the code that can cause the program to crash.

Keep the code that can safely crash the program

Record error information for your technical support staff

Make sure that the error messages remain in the Code are friendly.

8.8 being defensive about Defensive Programming

Defense posture for Defensive Programming

Excessive Defensive Programming can also cause problems. Consider what you need to defend against, and then adjust the priority of your defensive programming based on local conditions.

Checklist: Defensive Programming

Checklist: Defensive Programming

General

Does a subroutine protect itself from harmful input data?

Do you use assertions to describe program assumptions? Are the pre-and post-conditions included?

Is an assertion only used to explain what never happens?

Do you specify a specific set of error handling techniques in the architecture or high-level design?

Do you specify in the architecture or high-level design whether to make error handling more robust or correct?

Have you created a barrier to prevent possible damage caused by errors? Does it reduce the number of other codes that require attention to error handling?

Is the code that uses the auxiliary mode used in the code?

Do you need to enable or disable the added assistant?

Is the amount of Code introduced in defensive programming appropriate?

Are you using offensive programming in the development stage to make mistakes difficult to ignore?

Exception

Have you defined a standardized Exception Handling solution in the project?

Have you considered other alternatives to exceptions?

If possible, does the system handle the error locally instead of throwing it as an exception to the outside?

Does the code avoid throwing exceptions in constructor and destructor?

Are all exceptions at the same abstraction level as the subprograms that throw them?

Does each exception contain all background information about the exception?

Is no empty catch statement used in the code? (Or is it clear if an empty catch statement is used ?)

Security

Check whether the code that is harmful to input data also checks the failed buffer overflow, SQL injection, HTML injection, integer overflow, and other malicious input data?

Check all error return codes?

Have all exceptions been caught?

Whether error messages prevent information required by attackers to attack the system.

Key Points

Key Points

• The error handling method in the final product code is much more complicated than "garbage in and out.
• Defensive Programming Technology makes it easier to discover and modify errors, and reduces the damage caused by errors to product code.
• Assertions can help people discover errors as early as possible, especially in large systems with high reliability and rapidly changing code.
• The decision on how to handle error input is a key error handling decision and a key high-level design decision.
• Exception provides an error handling method that is different from the normal code process. If exceptions are used with caution, they can be a useful supplement to the programmer's knowledge toolbox. At the same time, they should be weighed and compared with other error handling methods.
• Product Code restrictions do not apply to software in development. You can use this advantage to add code that helps you troubleshoot errors more quickly in development.