UML software engineering organization
Beijing Dragon Fruit Software Engineering Technology Center
Program's robustness and self-defense
From liyuming1978
In fact, the robustness of the program (robustness) is the problem that you have to pay attention to each language. He is focused on the self-defense. 1. Object-oriented requirements Black box operation Since the object-oriented requirements, each part is independent of each other, then individual parts are strong enough to cope with the incorporation of input parameters. Although modern programming is pretreated, the general is to convert the input format to a unified format, and then processed. For example, now the online search engine is converted to Unicode format. But this is not to say that our handle is not required to handle it. Pretreatment can greatly reduce the probability of program error and write complexity of error handling. However, considering that individual modules become more intelligent, each blackbox should have independent behavior, error handling, and erroneous correction. 2. Error Capture and Error Information Compare the error handling relative to C and C language. It is nothing more than the conditional judgment statement (often misconduct is not good, but the programmer is not good, but it is more lazy, huh, huh). The problem you need to pay attention to here is how to write an error message. Error message To complete: Where is it, because what is wrong, what happened. Incomplete error messages do not have any available value. The other is the running log (log). Enter some information to the log file on the key step, prompting the current program to run to where (if possible, get the current error code of the system). This will use this log for a certain judgment when the program is accidentally interrupted. 3. Self-defense (prevention erupys) procedures should be as self-correction as possible. This is particularly important in the case of the input of the program. In fact, due to the reasons for cooperative development, there are many cases. A programmer prepared module is likely to have a specific requirement for the input, then a problem occurs when another programmer calls this module. A good treatment is to determine the input within the module. If there is an unisowed, make reasonable error correction, and valid prompts (under the Debug version). It is noted here that if it is correct, it is necessary to make a valid prompt: may be MSGBOX, or it can be written to log. Below is an example of a pseudo code: // This module is a statistical statistics for the date, and the holiday Function Stat (Time) {Int errcode; char * errstr [max] can also be defined as global variable IF (errcode = check) & Time)) {// In fact, this can be placed in the pre-processed FPRINTF ("" illegal input% D, correcting the day ", errcode); msgbox (errstr); // But for a separate module, if it is not guaranteed Processing Time = GetToday (); // // does not use this way. } IF (Errcode = Checkholiday (& Time)) {fprintf ("No Status for holiday% D, correction is the same", errcode); msgbox (errstr); time = gettoday ();}. . . . . . Treatment} There is no technical content in fact this. The key is that if there is no self-correction, once there is a mistake, the only way is to exit the program (or a single thread). This is what users don't want to see, use self-correction, and avoid some small errors lead to the abortment of the program.
Copyright: UML Software Engineering
