---
url: >-
  https://adk.nht.io/api/@nhtio/adk/exceptions/variables/E_TOKENIZABLE_EVALUATOR_INVALID.md
description: >-
  Thrown by {@link @nhtio/adk!Tokenizable} when a DYNAMIC (evaluatable) value's
  evaluator function fails to produce a usable string at resolve time — either
  it THREW, or it RETURNED A NON-STRING.
---

# Variable: E\_TOKENIZABLE\_EVALUATOR\_INVALID

```ts
const E_TOKENIZABLE_EVALUATOR_INVALID: CreatedException<[string]>;
```

Defined in: [src/lib/exceptions/runtime.ts:622](https://github.com/NHTIO/ADK/blob/v1.20260713.1/src/src/lib/exceptions/runtime.ts#L622)

Thrown by [@nhtio/adk!Tokenizable](../../common/classes/Tokenizable.md) when a DYNAMIC (evaluatable) value's evaluator function fails to
produce a usable string at resolve time — either it THREW, or it RETURNED A NON-STRING.

## Remarks

An evaluatable Tokenizable wraps a `(ctx?) => string` that is invoked at prompt-assembly time (and, with
no context, at measurement/serialization time). Both failure modes are PROGRAMMER errors, not recoverable
runtime conditions: an evaluator that throws is buggy, and a non-string return would otherwise coerce
silent garbage into the prompt (`undefined` → "undefined", an object → "\[object Object]"). So we surface
loudly rather than degrade — the only sanctioned fallback is the evaluator's OWN `ctx === undefined`
branch, which must itself return a string. Inside a runner the throw rides the nack → error seam (a
dispatch error / banner); outside a runner it propagates as the real bug it is.

The single printf argument describes the failure ("threw" or "returned a non-string (`type`)"); the
original error, when the evaluator threw, is attached on `cause`.