summaryrefslogtreecommitdiffstats
path: root/Sources/Cepis/CSV.swift
diff options
context:
space:
mode:
authorMurilo Ijanc <[email protected]>2026-07-27 20:33:24 -0300
committerMurilo Ijanc <[email protected]>2026-07-27 20:33:24 -0300
commitd7ca2d6f4b1c5c1f5f1b6ce6ffad35aaffee5b0f (patch)
tree21aca875c28f4d7d9ec3b0a807e7c7f15a6766d8 /Sources/Cepis/CSV.swift
parent72a4b451c9d06f7a97cac2f43f1b7f52fafcd3b7 (diff)
downloadswift-61a029a88b5988bf0eb3cac51f590223c5b02024.tar.gz
Carry the municipality on a not-found CEPHEADv0.2.0main
A CEP that fails a lookup is rarely a random number: it is almost always someone who knows the city and guessed the digits. The classic guess is the -000, which 957 municipalities never received. Answering that with a bare "not found" throws away what the API knows — that the number is in Areal/RJ's band — and leaves the caller unable to tell a typo apart from a city that has no such CEP. The 404 now carries an optional faixa, so cepNotFound carries it too. It decorates the error and never replaces it: the CEP still does not exist and the call still throws. Parsing is deliberately incapable of escalating — a faixa that is absent, null, empty or malformed becomes nil, because losing the decoration must never cost the clean not-found underneath it. Faixa offers no contains(): cep_ini and cep_fim are the smallest and largest CEP that actually exist, not the bounds the Correios publish, and the range between them is sparse — Areal's 118 CEPs are spread over some 4,900 numbers. Only a lookup can answer whether a CEP exists, and an API that appeared to answer it from the pair would be lying. Widening cepNotFound's payload breaks anyone matching the case with a single binding, hence 0.2.0.
Diffstat (limited to 'Sources/Cepis/CSV.swift')
0 files changed, 0 insertions, 0 deletions