| 
|
Topic: run-time assertions
topics >
computer science >
data >
debugging
Topic:
consistency testing
Topic:
constraints
Topic:
debugging techniques
Topic:
dynamic type checking
Topic:
error messages
Topic:
error safe systems
Topic:
exceptions from invalid input
Topic:
flavor analysis and typestates for supplementary type checking
Topic:
path expression
Topic:
program proof via assertions
Topic:
requirement specification by assertion
Topic:
range checking
Topic:
safe use of pointers
Topic:
type-safe and secure languages
Summary
An effective debugging tool and technique for robust programs is assertion statements which must be true. They can be validity checks on input, program state verification at the user level, or consistency checks before critical operations. They are especially valuable on pointer-based data structures, since one misplaced pointer can destroy a program's integrity. System support for assertion testing encourages its use. Sufficient support is an assert statement which generates an exception on failure. Each assertion needs a unique identifier for error messages. The system should recover gracefully from assertion failure. (cbb 5/80)
Subtopic: self-checking
Quote: check routines for class invariants are an invaluable help during debugging and class definition [»stroB_1991] Quote: check routines for class invariants provide an alternative viewpoint of the class and its implementation Quote: a self-protective component can check for error conditions before execution or asynchronously [»abboRJ3_1990]
Subtopic: assertions check actual execution
Quote: use assertions to fail fast; identifies difficult to detect and diagnose bugs; do not hide problems [»shorJ9_2004] Quote: system components should be self-protective and self-checking to prevent error propagation [»abboRJ3_1990] Quote: self-checking hardware either gives a correct answer or it signals failure [»abboRJ3_1990] Quote: produced a simple proof by adding run-time checks to all routines that modified file structures [»andeT_1985] Quote: a system should be intelligent, i.e., help the user and reduce workload; e.g., check all inputs for validity [»potaWA_1979] Quote: use run-time data maps and data indirections to ensure correctness of run-time data transformations
Subtopic: debugging
Quote: it is absurd to make elaborate security checks on debugging runs, and then remove them in production runs, when an erroneous result could be disastrous [»hoarCA_1974] Quote: do not disable assertions in the field; needed for identifying problems [»shorJ9_2004] Quote: add assertions which give the correct result for an example execution; machine-checked; made program easier to understand [»morrJH_1980] Quote: SafeTSA includes safe-ref that cannot be null, and safe-index-arr that cannot be out of range; via runtime checks [»ammeW6_2001] Quote: Pearl includes assertions about a function; e.g., clear (Queue a) ... Yields empty (a) [»snowRA_1973, OK] Quote: violations of assertions indicate bugs; can control the level for checking assertions [»meyeB10_1992] Quote: run-time annotation checking is practical because it checks individual executions, while verification checks the entire state space [»sankS3_1991]
Subtopic: forced failures
Quote: Guard performs relative debugging with assertions to compare data structures, permutations to identify subarrays, and plots of error surfaces
Subtopic: input validation
Quote: use ATAfakeIt to force an assertion failure when testing code; exercise each assertion [»millKW3_2001]
Subtopic: assert statement
QuoteRef: bateD_1974 ;;58 Hartz ?: need to verify input at all points QuoteRef: seedH_1971 ;;42 inputs as named sequences with associate "record identifying indicator' which is on when current card is of the sequence, sequence id by boolean rela on column contents QuoteRef: seedH_1971 ;;121 full order checking on input fields by indicators
Quote: descriptive assertions near the point of failure [»shorJ9_2004] Quote: implement own assertion class for greater expressiveness and convenience [»shorJ9_2004] QuoteRef: siteRL8_1971 ;;49 assert logical-expression; terminate execution if expression is false (for error checking) QuoteRef: sattEH5_1975 ;;13 assertion statements which force an error when false
Group: debugging (10 topics, 333 quotes)
Topic: consistency testing (60 items)
Topic: constraints (35 items)
Topic: debugging techniques (23 items)
Topic: dynamic type checking (43 items)
Topic: error messages (37 items)
Topic: error safe systems (76 items)
Topic: exceptions from invalid input (4 items)
Topic: flavor analysis and typestates for supplementary type checking (68 items)
Topic: path expression (14 items)
Topic: program proof via assertions (61 items)
Topic: requirement specification by assertion (28 items)
Topic: range checking (20 items)
Topic: safe use of pointers (102 items)
Topic: type-safe and secure languages
(43 items)