8. Chapter review

No. try_fields is defensive programming: it prevents a crash when the expected field name is missing by trying alternatives. It does not reject bad data, it accommodates variation. Validation is the discipline of rejecting data that does not meet a rule: an empty string, a -999 placeholder, an email without an @. The two are complementary and both should be present, but they are not interchangeable and relabelling one as the other is how gaps ship.

Every layer depends on the previous one having succeeded. Content validation starts with if temp < -100, which assumes temp is a number, a structural claim. Business-rule validation compares apparent_temp to temp, which assumes both fields exist and are numeric, a content claim. Run the layers out of order and you either crash (business rules hitting missing keys) or produce meaningless errors (content checks reporting range failures on strings).

The hybrid approach. Twelve fields with individual type and range rules is exactly the shape JSON Schema handles well -- twelve near-identical manual validators are the repetition schemas were designed to eliminate. Three cross-field invariants are likely to be clearer and easier to test as hand-written Python. Start with the schema, add the business-rule function, chain them in a fail-fast pipeline. Pure manual would be a wall of repetitive validator code; pure schema would make the three invariants harder to understand and maintain.

In the service layer. The API client does not know or care about domain constraints (snow at 15°C is a business fact, not an API-contract fact), and the application layer already assumes domain constraints hold before it displays or stores. Structural and content validation belong in the API client; business rules belong in the service layer; display logic belongs in the application layer.

Temperature is load-bearing (the whole UI renders against it), so an invalid temperature is fail-fast: raise or return a hard error, refuse to proceed. The weather-code icon is an enhancement (the dashboard is useful without it), so an invalid code is fail-graceful: log a warning, set the field to None, let the UI fall back to a default icon. The rule is criticality-per-field: essential data fails hard, enhancements degrade.

Schema handles well: type checking ("temperature must be a number"), range validation ("humidity between 0 and 100"), required fields ("temperature_2m must be present"). Also string patterns via regex, enumerated values, and nested-object structure. Schema handles poorly or awkwardly: domain comparisons (snow codes at warm temperatures), rules that need outside context (whether a payment amount exceeds a user's credit limit), and array-by-array comparisons (whether temp_min[i] <= temp_max[i] for every day). JSON Schema has conditional keywords for some relationship rules, but these three are clearer as hand-written Python validator functions chained after the schema in a hybrid pipeline.

They are complementary, not alternatives. safe_get and try_fields prevent crashes when data structures are missing or nested deeply -- they are defensive programming, the "do not blow up on surprises" discipline. Validators in this chapter reject data that is present but wrong -- they are the "the data must satisfy a rule" discipline. In a production codebase you use both: the normalizer reads with safe_get to avoid KeyError, and the validator checks the extracted values against rules before the data flows downstream. Defensive programming protects your code; validation protects your output.