bcquality/community/knowledge/error-handling/fielderror-vs-testfield.md
Jeremy Vyska 4119417ce4
Some checks failed
Validate knowledge index / validate-index (push) Has been cancelled
Validate frontmatter and structure / validate (push) Has been cancelled
Add 15 community knowledge articles from BC Code Intel ingest (#66)
* Add 15 community knowledge articles from BC Code Intel ingest

Ingests net-new /community knowledge from BC Code Intelligence, surviving
the admission test, gray-zone salvage, and dedup against the full corpus.

Domains: ui (6), error-handling (3), performance (2), upgrade (1),
appsource (1), security (1), telemetry (1). The two BC24 No. Series
migration drafts are merged into one article.

Adds good/bad AL samples for the clean-fit articles (error-handling,
performance, security, telemetry). UI and appsource remain knowledge-only.

Validator and knowledge-index checks pass (207 articles).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* Correct SetLoadFields JIT-load article to match MS docs

The draft claimed accessing an unlisted field "reloads the entire row"
per record. Microsoft's partial-records docs say otherwise: the platform
does an implicit Get that loads the missing field(s), and in a direct var
loop the first JIT updates the enumerator so later iterations do not
re-load. The genuine per-row penalty is the pass-by-value case, where the
copy's enumerator is not updated.

Rewrite the article around JIT loading and the by-value footgun, rename
the slug from ...full-reload to ...jit-load, and fix the good/bad samples
to demonstrate the by-value repetition accurately.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Jeremy Vyska <jeremy@sparebrained.com>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-01 14:31:50 +02:00

2.1 KiB

bc-version domain keywords technologies countries application-area
all
error-handling
fielderror
testfield
field-validation
onvalidate
error-message
mandatory-field
record-context
al
w1
all

Choose TestField For Conditional Checks And FieldError For Already-Failed Validation

Contributions welcome — open a PR to refine or extend this article.

Description

TestField and FieldError look interchangeable but behave differently, and choosing the wrong one produces either dead code or a check that never fires. TestField performs the comparison itself and throws only when the field is empty or does not match the supplied value; FieldError performs no comparison and always raises an error the moment it is reached. Both attach the field caption and the record's primary-key context to the message automatically, which is why neither should be replaced by a hand-built Error call that interpolates the field name as a literal.

Best Practice

Use TestField when the condition is a simple presence-or-equality check on a single field — mandatory-field gates and prerequisite checks at the top of a procedure read clearly and self-document intent. Use FieldError inside an OnValidate trigger or a validation procedure where surrounding business logic has already determined the value is invalid and you want a specific, custom message. Rely on the built-in field-and-record context both methods add rather than re-stating the field name in the text.

Anti Pattern

Calling FieldError to "test" a field — placing it on a path that is reached unconditionally and expecting it to validate — terminates execution every time because FieldError never evaluates a condition. The inverse smell is reaching for TestField when the rule needs a tailored message, then bolting a vague generic string onto a check that cannot express the real business reason. A reviewer can spot the first by a FieldError that is not guarded by a preceding if, and the second by a TestField whose intent comment describes a condition more complex than presence or equality.