Software Quality and Defensive Programming

Software Quality and Defensive Programming

• Software quality is enhanced through defensive programming, testing, and debugging.
• Defensive programming involves preventing problems
• Testing determines if code is working correctly
• Debugging fixes defects found in testing.

Purpose of Defensive Programming

• Primary goal to detect problems early in the development cycle.
• An error handling strategy is a must
• Error handling strategy ensures a consistent approach to error management throughout the system.
• It is crucial to decide how to handle runtime errors uncovered by defensive programming.
• Must balance comprehensive error checking with practical considerations.

Software Quality Factors: Robustness

• Robustness is the ability to maintain correct, predictable, and stable behavior even when errors occur.
• Errors can occur in commercial and open-source software.
• Defensive programming writes code to detect and manage runtime errors.
• Testing to find defects in source code
• Debugging, the fixing of those defects

Defensive Programming Principles

• It is similar to defensive driving where "unexpected" problems emerge
• Anticipate potential errors in various areas:
  • Input data
  • Function arguments
  • File contents
  • Human input
  • Module behavior

Error Analysis

• Treatment depends on the phase of software development and also factors such as "kinds" and "severities" of errors.
• Different errors have varying characteristics and severities, impacting the possibility of continuing execution.
• It matters if the program is in debugging or production.

Error Types

• There are three types of errors:
  • External errors which are outside of the control of your program
  • Internal, regarding software usage
  • Rare conditions which could be your software's fault
• Fatal Errors:
  • These prevent a program from continuing execution and are often due to issues.
  • Issues can include out-of-memory errors, null pointers, nonsensical variable values etc
  • Best to abort and provide information for diagnosis.
• Nonfatal Errors:
  • Examples, failure to open a file or invalid phone number format.
  • During testing/debugging, notify programmers before aborting.
  • In production, maintain running and recover gracefully.

Error Handling: Local vs. Upward Reflection

• Handle errors in the context where they are detected
• Handle as close as possible to the point of detection.
• Benefits include preventing invalid states from propagating and improving code documentation.
• Some errors may need to be reflected upward, especially in utility packages.
• Errors of this type may not be handled acceptably at a higher level.
• Caller must implement "handle error in context."

Tools for Error Reporting

• Printing allows for recovery/continuation
• Tools include conditional reporting with print & abort or continue quietly.
• Utilize assert(expression) for debugging.
• Asserts are less useful in production code.

Defensive Programming Checks

• Verify cases and extreme values just in case.
• Example

if ( grade < 0 || grade > 100 ) /* impossible grades! */
 letter = '?';
else if ( grade >= 80 )
 letter = 'A';
else...

• Internal Checks:
  • Check for potential problems like NULL pointers, out-of-range subscripts, default switch cases, and division by zero.
  • Always attempt to return an error and use asserts during development, while removing them in production.

Pre- and Post-Conditions

• Ensure necessary conditions hold before and after critical code sections.
• Consider potential recovery strategies.
• The USS Yorktown incident demonstrates the importance of preventing divide-by-zero errors.
• Verify preconditions to prevent dangerous operations.

Error Return Checks

• Verify error returns
• Check values from library functions and system calls.
• Monitor output errors and failures, with input failures
• Review scanf and printf for number of scanned/printed arguments.
• Bad status should print error number

Error Handling in C

• C functions signal errors, particularly through pointer returns.
• NULL indicates an issue, while non-pointer returns rely on "invalid" values like NaN.
• A function may return an error code, using the return value by reference, or return a pointer to the new value, using NULL to signal an error

Error Handling in Other Languages

• Languages like Java, Python, and JavaScript use exception handling.
• Exception handling provides a function returns a value if things go well, throws an exception otherwise
• Nullable types, are used for handling errors
• C lacks nullable types, unlike Java and other languages.

Defensive Programming and Testing

• It serves as a form of self-testing code during development and production, complemented by later testing phases.

Assertions: Usage

• Assertions are supported in modern programming languages
• They permit checking conditions, continuing if true, and exiting with an error message if false.
• Expression equaling zero indicates falsehood.
• Fails the assertion and results in a message on stdout and a call to abort()
• Assertions should handle improbable conditions from bugs with the intention to abort and verify preconditions.
• Don't use for user input data
• Assertions abort program on error.

Assertions: Control

• Assertions are turned on by default and include helpful printouts.
• They can be turned off at compile time using #define NDEBUG or -DNDEBUG in the makefile.
• Usage depends on application-wide error handling policy.
• Assertions should not have side effects.

Understanding Code Failure

• Code can fail if implicit preconditions, are not checked.
• An example includes calculating the average.
• Code fails when using no arguments, resulting in NaN.

Assertions in Practice

• Include <assert.h> and use assert(n > 0) in the average function to check for valid input.
• Verify precondition of avg() - catches bug in main for cases where main should check for 0 args
• Main reason, catch it during development phase
• Turning of assertions during production

Assertions: Misuse

• Do not check the number of arguments with assert() in main().
• It's bad because input with 0 arguments is external
• Assertions alone aren't a Substitute for input validation code
• Should easily recover bad input

Assertions: Good vs Bad

// GOOD
int *arr;
arr = malloc(20*sizeof(int));
assert( arr != NULL ); // states what condition should be true
assert( arr ); // same meaning, NULL ptr. compares equal to 0 (false)

// BAD
int *arr;
assert( arr = malloc(20*sizeof(int)) ); // saved a line of code!
// But if assertions are disabled (-DNDEBUG), this malloc will disappear!

Partial Functions

• In math, some inputs may have no possible output
• On the other hand, Colloquially, a partial function maps some (but not all!) of the possibles inputs from the domain (input set) X to some element in the codomain (set containing outputs) Y
• A partial function is a function whose output is undefined for some inputs, like sqrt(), log(), log10().
• When programming, partial functions are a problem if their algebraic equivalent is undefined.
• This is because they can crash, crash politely (abort) or return an “impossible” value
• A function that for some inputs returns a value and for others terminates your program is hard to reason about / debug
• Dying too early may not inform the end user of cause.
• Want it to return something rather than nothing, even with negative numbers, for example.

Partial Functions: IEEE

• It specifies the way that sqrt() should be called.
• It always returns a return value, if x >= 0, or NaN if x<0

Assertions and Partial Functions

• Careless use can make partial use functions
• Always signal an error, but dont assume the function will
• Remember there are a few occasions assert() must be used.
• Assertions help you avoid logic errors like you avoided them.

Conclusion

• Verification:
• Always verify input
• Error Handling:
• Always try to return an error and abort.
• User Interface:
• Let UI communicate all errors
• Assumptions:
• Always assume all function arguments are always valid.