Handle One Expected Failure

Keep numeric conversion in a narrow try block, catch only its expected ValueError, state the local response, and leave unrelated defects visible.

A program should continue after a failure only when it knows what the failure means and what to do next. In the measurement program, a reading such as "not recorded" is expected occasionally. It cannot become a number, but the other readings can still be processed.

Put Only the Expected Operation in `try`

The failure occurs at one boundary: converting text to a number. That is the only operation that belongs in the try block.

Python first runs the statement under try. If float(text) raises ValueError, execution moves to the matching except block. The name error refers to the exception value, so the report can include Python's explanation.

The block is deliberately small. It says exactly which operation we expected to fail. If several unrelated statements were placed under try, the handler could respond to a ValueError from the wrong operation and send us looking in the wrong place.

Q1. Choose the narrow boundary

Which try block states the expected failure most clearly?

Choose one

Place only reading = float(text) in the try block.

Place the whole loop, report, and summary in the try block.

Put no statement in try and catch the failure after the program stops.

Select one choice, then check.

HintName the expected operation

The stated problem is invalid numeric text, not failure anywhere in the measurement loop.

SolutionProtect only conversion

Put only reading = float(text) under try. The handler then has one clear meaning: this row did not contain usable numeric text.

State the Response

Catching an exception is not a complete policy. The program must decide what happens to the affected row. Here we report the rejected row and skip it:

The output makes both parts of the result visible:

Skipped east: could not convert string to float: 'not recorded'
Accepted: [('north', 18.0), ('west', 23.0)]

continue begins the next loop iteration. Without it, the program could reach accepted.append((label, reading)) even though this iteration never produced a new reading. Reporting the row prevents the skip from becoming silent.

This is recovery, not repair. The text still cannot be converted. The program has a stated response that allows the remaining records to be useful. In a different program, losing a row might be unacceptable; that boundary should reject the input instead. The response belongs to the program's contract, not to the spelling of try and except.

Q2. Report and skip one row

Complete the handler so the program reports the invalid row, skips it, and keeps both valid readings.

Editable Python

HintLeave append on the successful path

Catch ValueError as error, report label, and use continue. The append statement should run only when conversion succeeds.

SolutionHandle the conversion failure locally

Leave Unrelated Defects Visible

A specific handler protects a specific boundary. It should not turn every failure into a skipped row. Suppose append is misspelled:

accepted.apend((label, reading))

Python raises AttributeError. The except ValueError block does not match, so the program stops and shows the new defect. That is useful. The program has no defined recovery rule for a misspelled method.

A broad handler such as except Exception: would blur the distinction. If it also printed nothing, the program could quietly lose valid rows. We would see an incomplete report instead of the defect that caused it.

Event	Local policy	Result
`float("not recorded")` raises `ValueError`	Report and skip that row	Continue
`accepted.apend(...)` raises `AttributeError`	No expected response	Stop and debug

Q3. Keep a programming defect visible

The conversion handler catches ValueError. A valid row later reaches accepted.apend((label, reading)). What should happen?

Choose one

AttributeError should stop the program and remain visible.

The ValueError handler should skip the row.

A broad handler should ignore the failure and continue silently.

Select one choice, then check.

HintMatch the exception to the policy

The local policy covers invalid numeric text and ValueError only.

SolutionDo not hide an unrelated defect

apend is not a list method, so Python raises AttributeError. The specific ValueError handler does not catch it. The program stops with evidence of a programming defect that must be repaired.

Handle an exception only when one expected operation has a stated response. Keep the try block narrow, catch ValueError specifically, and report the skipped row. Other failures should remain visible. When a larger failure is still hard to explain, the next step is to reduce it without changing it.