In defensive programming, what is the intended outcome?

• A. The device continues to work even if some errors occur
• B. The device refuses to start if any error is detected
• C. The software automatically repairs hardware faults
• D. Errors are ignored during execution

Answer: (A)

Defensive programming aims to make software tolerate errors and continue operating. The intended outcome is that the device keeps working even if some errors occur, by validating inputs, checking for fault conditions, handling exceptions, and providing safe fallbacks or degraded functionality rather than crashing. In practice, this means designing for things like unexpected input, partial hardware failures, or temporary network issues, and having the program respond gracefully—use defaults, retry when sensible, clamp out-of-range values, or switch to a safe mode—so service remains available.

Choices that suggest refusing to start on any error, automatically repairing hardware faults, or ignoring errors don’t fit this goal. Refusing to start would make the system brittle and reduce availability; automatic hardware repair is typically outside software’s domain; and ignoring errors undermines reliability and safety.