3.6.2 Outline methods of detection and prevention for each of the errors in 3.6.1.
Teaching Note:
Verification and validation should be understood. Check digits and
hash totals should be explained. The use of modulo operators (mod,
div) in constructing check digits should be understood.
Sample Question:
...Every time the price for an individual product increases or decreases, a central program
updates the file in each city. The program does this by opening each file over the
network and updating the required data.
The product code is simply a number between 1 and 999.
(a) Describe two data validation techniques that could be used to validate a product
code when it is entered. [2 marks]
JSR Notes:
And now you take the examples either you've come up with, or the ones in the case study, and you describe how these specific errors can be prevented or detected.
Logic mistake or oversight in error handling:
Proper software debugging and testing - and use of good Object Oriented Programming principles.
Accidental electro-magnetic interference:
Use of parity checking, check sums and check digits.
Student hacks into a school computer:
Passwords used on teacher accounts - could it be possible that teachers would not password protect their accounts!!???!!!
Repeated crashes of a particular software program:
Proper software debugging and testing - and use of good Object Oriented Programming principles.
Internal teacher e-mails missing characters:
Use of parity checking, check sums and check digits.
In terms of these error-handling techniques, the textbook does a good job, but some highlights and clarifications:
Both validation and verification are necessary. In terms of keeping the terms straight, they mean what they mean. Valid means valid, and to verify something simply means that you are checking to see if what is on the rough paper is what was input. But you can always input invalid data "correctly": Invalid data can be verified, but it will still be invalid - as they say, "Garbage in, garbage out."
Remember the three categories of validation as described on page 202.
Use of check digits is another example, like parity checking and check sums, where a calculation is made on data before and after transmission, and so if the data has been unaltered the result of that identical calculation should be identical; if not, there's been an error in transmission, and a request for re-transmission should be made.
And remember that though weighted heck digits are better nothing is ever totally fool-proof if there happen to be coincidental errors which cancel each other out.
And in terms of software related errors and the difference between syntax, logic, and run-time errors:
Syntax errors should have been caught by a compiler anyway.
Logic errors should be caught by adequate testing, and, well, thinking.
Runtime errors are errors that happen after the program is out on the market, and so these are the ones that were hard to deal with. Runtime errors are not logic errors, though they very well may be blamed on poor programming. Runtime errors are generally caused by errors of omission, but these are often, in turn, a result of situations that were difficult or impossible to anticipate. One good example is interference by another an application or operating system feature that did not exist at the time of programming. Meantime, though, "division by zero", and "file not found" errors, are still classified as runtime errors, they should have been dealt with through proper error handling techniques by the programmer.