The Report That Counts Wrong
A payroll script sums a list of daily hours for each employee. Each employee's hours are stored as strings (e.g., "8", "7.5"). The script concatenates the strings instead of adding numbers, so an employee with days "8" and "7" reports "87" hours instead of 15. The developer adds a fix that converts each value to a number before summing. A second bug then appears: one employee's record contains the text "n/a" for a day off, and the conversion fails, aborting the entire payroll run. The developer is tempted to wrap the whole loop in a single try/except that skips any record that errors.
1. Explain the root cause of the "87" result and why type conversion was the correct direction of fix.
Read the worked answer
The + operator is overloaded by type: for strings it means concatenation, for numbers it means addition. Because the hours were stored as strings, "8" + "7" produced "87".
The root cause is a type mismatch between how the data was stored (text) and how it was used (arithmetic). Converting to a number before summing is the correct fix because it aligns the data type with the intended operation. The alternative - changing the operation - is not available, since there is no 'add' that means numeric addition on strings. The lesson: the meaning of an operator depends on its operands, so data types must match the intended semantics before the operation is applied.
2. Critique the plan to wrap the entire loop in one try/except that skips any record that errors.
Read the worked answer
A blanket try/except around the whole loop is too coarse:
- It hides the cause. Any error - a typo, a missing field, a genuine bug - silently drops a record, so the payroll may be quietly wrong with no signal.
- It may abort or skip more than intended, because one bad record can prevent later good records from being processed depending on where the exception is caught.
- It treats a data-quality problem ("n/a" means zero hours or a day off) as an exception, when it is actually an expected, known case.
Better: handle the known case explicitly (treat "n/a" as 0 hours, or skip with a logged note), and let genuinely unexpected errors surface so they can be fixed. Catch narrowly and specifically, not broadly.
3. Describe a test that would have caught the "87" bug before release.
Read the worked answer
A test using known input with a hand-computed expected output: feed an employee with hours "8" and "7" and assert the total equals 15 (a number), not "87".
This works because it checks the value and type of the result against an independently calculated answer, rather than merely checking that the program runs. A test that only confirmed 'the script completes' would pass even while producing "87". Comparing against a hand-computed expected value is what exposes the type error.