diff options
| author | Murilo Ijanc <[email protected]> | 2026-07-27 20:42:22 -0300 |
|---|---|---|
| committer | Murilo Ijanc <[email protected]> | 2026-07-27 20:42:22 -0300 |
| commit | b6f876f8b0847c223f3310d3e5208d78982a13c1 (patch) | |
| tree | fce85d75a2e491b6514a4ed7c42dca898f944cc5 /Makefile | |
| parent | cf5597871327dbff2c7c743672d696e7ff340c42 (diff) | |
| download | pascal-6637db2cb939c538c039b501ba9d827f07545208.tar.gz | |
A CEP that fails is rarely a random number: it is usually someone who knows
the city and guessed the last digits, and the classic guess is the -000 that
957 municipalities never received. The API now answers those 404s with a
faixa block naming the municipality the number would have belonged to, which
is enough to tell the user "no such CEP in Areal" instead of just "not found".
It stays an error. ECepisNotFound carries the block as a TCepisFaixa and owns
it, the same way an address owns its geo, so no shape of the response can turn
a not-found into an address. Parsing is tolerant on purpose: a faixa that is
absent, null, empty or unreadable leaves Faixa nil rather than costing the
caller the clean not-found underneath.
CepIni and CepFim are the first and the last CEP that actually exist in the
municipality - not the bounds the Correios publish, whose start for Areal is
the very CEP that just failed - and the range between them is sparse. That is
what Ceps is for, and why the comments insist the pair is not a list.
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions