Errors¶
Crease's error model is pydantic-shaped: every problem the library
surfaces — whether structural (template can't map the file) or cell-level
(a value violated a constraint) — is represented as the same Error
type, with the same five fields.
Error
dataclass
¶
Error(
type: str,
loc: tuple[str | int | None, ...],
msg: str = "",
input: Any = None,
ctx: dict[str, Any] = dict(),
severity: Severity = "cell",
)
A single problem surfaced by crease.
Fields mirror pydantic.ValidationError.errors() entries, with one crease
addition: severity distinguishes structural errors (the template can't
map the file at all) from cell-level errors (an individual value
violated a constraint).
Attributes:
| Name | Type | Description |
|---|---|---|
type |
str
|
Stable machine code for routing — e.g. |
loc |
tuple[str | int | None, ...]
|
|
msg |
str
|
Human-readable description. |
input |
Any
|
The offending value, if applicable. |
ctx |
dict[str, Any]
|
Extra context — for example |
severity |
Severity
|
|
ValidationError ¶
Bases: Exception
Raised by halt-by-default projection methods when crease has errors to report.
The exception carries the full Error list — same shape as
Report.errors() would have produced. Pattern after Pydantic's
ValidationError:
try:
orders = result.to_pydantic("order", model=Order)
except crease.ValidationError as e:
for err in e.errors():
print(err.type, err.loc, err.msg)
Error type taxonomy¶
The error.type field is a stable machine code safe to route on. The
full taxonomy is in the README's error table.