Shulou(Shulou.com)06/01 Report--

How to implement defensive programming? In response to this problem, the editor today summarizes this article on defensive programming, hoping to help more friends who want to solve this problem to find a more simple and easy way.

The whole point of defensive programming is to defend against mistakes you didn't expect.

The main idea of defensive programming: subroutines should not be destroyed by passing in error data, even if other subroutines produce error data. More generally, the core idea is to admit that all programs have problems and need to be modified, and smart programmers should program according to this.

First, protect the program from illegal data entry

For software that has formed a product: no matter what the incoming data, the labor process should not spam data. (necessary error prompt)

There are usually three ways to deal with incoming junk data:

1. Check all values from external data

When getting data from a file, user, network, or other external interface, you should check the obtained data value to make sure it is within the allowed range.

2. Check the values of all input parameters of the subroutine

The data comes from other subroutines, not external interfaces.

3. Decide how to handle the wrong input data

Once illegal data is detected, it should be processed.

Note: guard against seemingly minor mistakes, and the gains may be far beyond your imagination.

II. Assertion (Assertions)

Assertion definition: code (usually a subroutine or macro) that is used during development to allow a program to self-check at run time. (especially important for large complex programs or programs with high reliability requirements)

Java asserts: two parameters-> assert ("bool expression", "error message when the judgment condition is false")

Assertions check for such assumptions as:

1. The values of input parameters and output parameters are within the expected range.

2. When the subroutine starts (or ends) execution, the file or stream is open (or closed).

3. When the subroutine starts (or ends), the read and write position of the file or stream is at the beginning (or end).

4. The file or stream has been opened in a read-only, write-only, or read-writable manner.

5. The value of the variable that is only used for input is not modified by the subroutine.

6. The pointer is not null.

7. The array or other container passed into the subroutine can hold at least X data elements.

8. The table has been initialized and stores real data.

9. When a subroutine starts (or ends) execution, a container is empty (full).

Note: assertions are mainly used in the development and maintenance phases and are not compiled into the object code when the product code is generated so as not to degrade system performance.

1. Establish your own assertion mechanism.

Assertions are supported in many languages, including C++, Java, and VB.

"the standard assert macros in C++ do not support text messages.

2. Guidelines for the use of assertions

Guidelines for assertions:

Use error handling code to deal with situations that are expected to occur, and assertions to deal with situations that should never happen.

When an exception occurs and an assertion is triggered, the source code of the program should be modified and recompiled.

Avoid putting code that needs to be executed in assertions

A dangerous way to use assertions (if the assertion is closed, the code cannot be compiled):

Debug.Assert (PerformAction ())

Use assertions safely

ActionPerformed = PerformAction ()

Debug.Assert (actionPerformed)

Annotate and verify pre-and post-conditions with assertions

"if the data comes from outside the system, you should use error handling code to check and process illegal values.

Assertions are appropriate if the value of a variable comes from within a trusted system.

For highly robust code, you should use assertions before handling errors

The assertion Microsoft Word, in its code, adds assertions to conditions that should always be true, but also handles these errors with error-handling code in response to assertion failure.

Third, error handling technology

How to deal with expected program errors:

Returns a neutral value, swaps with the next correct data, returns the same value as the previous one, swaps with the nearest valid value, logs a warning message in a log file, returns an error code, calls an error handling subroutine or object, displays an error message, or closes the program.

1. Return a neutral value

Sometimes, the best practice for handling errors is to continue with the operation and simply return a harmless value.

For example, numeric operations can return 0, string operations can return empty strings, and pointer operations can return null pointers.

2. Switch to the next correct data

For example: database record reading, file line information reading, and so on.

3. Return the same data as the previous one

4. Switch to the nearest legal value

For example, the speedometer of a car cannot show a negative speed, so when backing up, it simply shows 0.

5. Record the warning information in the log file

Consider whether it can be safely exposed, or whether it needs to be encrypted or protected in other ways.

6. Return an error code

Administrators can decide to let some parts of the system handle the error, while others do not handle the error locally, but simply report that an error occurred.

Adopt the method:

Setting the value of a state variable

The status value is used as the return value of the function.

Throw an exception using the built-in exception mechanism of the language

Note: if security is important, make sure that the caller's subroutine always checks for errors returned.

7. Call error handling subroutine or object

Error handling can be centralized in a global error handling subroutine or object.

Advantages: the ability to centralize the responsibilities of error handling, making debugging easier.

Cons: the whole program needs to be aware of this focus point and closely coupled with it.

8. An error message is displayed when an error occurs

Errors can reduce the cost of error handling.

9. Handle errors locally in the most appropriate way

While giving programmers flexibility, they also bring significant risks. That is, the overall performance of the system will not be able to meet the requirements for its correctness or reliability.

10. Close the program

"applies to applications that are critical to personal safety.

Robustness and correctness

The most appropriate way to handle errors depends on the type of software in which the error occurs. Error handling sometimes focuses more on correctness and sometimes on robustness.

Correct: it means that inaccurate results are never returned, even if they are not returned, it is better than inaccurate results.

Robustness: it means constantly trying to take steps to ensure that the software continues to work, even if it sometimes produces inaccurate results.

The influence of High-level Design on error handling

Illegal parameters are handled in a consistent and uniform manner throughout the program.

Determine a common way to handle error parameters, which is an architectural (high-level) design decision.

"once a method has been identified, make sure that it is consistently implemented.

Please check the error code after each system call.

IV. Anomalies

Recommendations for handling exceptions:

1. An exception is used to notify the rest of the program that an error that cannot be ignored has occurred.

The advantage of the exception mechanism is that it can provide an error notification mechanism that can not be ignored.

2. Throw an exception only in the case of a real exception

Exceptions are used only if other coding practices cannot solve them.

Exceptions are similar to assertions: they are used to deal with situations that are not only rare but never should have happened.

Abnormal trade-off:

1. Exceptions are a powerful way to deal with unexpected situations.

2. As a result, the complexity of the program increases and the performance may decrease.

3. Exceptions can not be used to shirk responsibility.

Errors that can be handled locally should be handled locally and should not be thrown as exceptions.

4. Avoid throwing exceptions in constructors and destructors unless you catch them in the same place

If an exception is thrown in the constructor, the destructor will not be called, resulting in potential resource leakage.

5. Throw an exception at the appropriate level of abstraction

When you decide to pass an exception to the caller, make sure that the level of abstraction of the exception is consistent with that of the subroutine interface.

6. Add all the information that caused the exception to the exception message

Make sure that the exception information contains all the information you need to understand why the exception was thrown.

7. Avoid using empty catch statements

Note or logging information documents this situation.

8. Know the exceptions that may run out of all the function libraries

Be sure to know what exceptions are thrown by the library you are using.

Failure to catch an exception thrown by the library will cause the program to crash.

9. Consider creating a centralized exception reporting mechanism

Exceptions can provide a centralized storage for some information related to exceptions, such as the types of exceptions that occur, how each exception should be handled, and how to format exception information.

10. Standardize the use of exceptions in the project

If you use a language like C++, you should specify exactly what kinds of exceptions can be thrown. (consider throwing only objects derived from the std::exception base class)

Consider creating project-specific exception classes (used as the base class for possible exceptions to the project, so that operations such as logging, error reporting, and so on can be centralized and standardized).

Errors specify where code is allowed to use try-catch statements to handle errors locally.

Exceptions specifies where code is allowed to throw exceptions that are not handled locally.

Determine whether to use a centralized exception reporting mechanism.

Exceptions specifies whether exceptions are allowed in constructors and destructors.

11. Consider the replacement scheme with exception

Please consider whether your system really needs an exception.

5. Isolate the procedure to contain the damage caused by the error

Barricade is a damage tolerance strategy.

1. Use this approach at the class level:

The public methods of the classes can assume that the data is insecure, and they are responsible for checking the data and cleaning it. Once the public methods of the class accept the data, then the private methods of the class can assume that the data is secure.

2. The relationship between partitions and assertions:

The use of separate columns makes a clear distinction between assertion and error handling.

Programs outside the column should apply error handling techniques, while programs inside the column should use assertion techniques.

VI. Code that assists debugging

Another important aspect of defensive programming is the application of a debugging assistant (auxiliary debugging code).

1. Do not automatically impose product version restrictions on the development version

"programmers often have the misconception that the limitations of production-level software should also be reflected in the development version (speed, resource limitations).

Developers should sacrifice some speed and resource use during the development phase in exchange for some built-in tools (auxiliary code) that make development smooth.

2. Introduce auxiliary debugging code as soon as possible.

The sooner you introduce debugging-aiding code, the more helpful it will be.

3. Adopt offensive programming

Exceptions should be handled in such a way that they are made visible during the development phase and self-healing while the production code is running. -"offensive programming"

The method of offensive programming:

Make sure that the assertion statement is the termination of the program.

Completely populate all allocated memory so that you can detect memory allocation errors.

4. Plan to remove debug assist code

Plan in advance to avoid entanglement between debugging code and program code.

Approach: "use version control tools like ant and make and make tools (you can compile different versions of programs from the same set of source code)" use built-in preprocessors "write your own preprocessors" and use debug stubs (stubs) (two sets of scenarios-development version and release version code)

7. Determine how much defensive code to keep in the product code

Take a defensive attitude towards defensive programming

After reading this article, have you learned to use defensive programming? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel. Thank you for reading.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.