eldritch horrors
08252967a8
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
(cherry picked from commit c6a89c1a1659b31694c0fbcd21d78a6dd521c732)
Change-Id: Iced91ba4e00ca9e801518071fb43798936cbd05a
22 lines
647 B
Plaintext
22 lines
647 B
Plaintext
error:
|
|
… while evaluating the attribute 'puppy."${key}"'
|
|
at /pwd/lang/eval-fail-attr-name-type.nix:3:5:
|
|
2| attrs = {
|
|
3| puppy.doggy = {};
|
|
| ^
|
|
4| };
|
|
|
|
… while evaluating an attribute name
|
|
at /pwd/lang/eval-fail-attr-name-type.nix:7:17:
|
|
6| in
|
|
7| attrs.puppy.${key}
|
|
| ^
|
|
8|
|
|
|
|
error: expected a string but found an integer: 1
|
|
at /pwd/lang/eval-fail-attr-name-type.nix:7:17:
|
|
6| in
|
|
7| attrs.puppy.${key}
|
|
| ^
|
|
8|
|