How would you write a Proxy 'set' trap that validates a value before allowing an assignment, and what happens if you return false?

Q: How would you write a Proxy 'set' trap that validates a value before allowing an assignment, and what happens if you return false?

**Target Audience:** Engineers preparing for JavaScript meta-programming and data-validation interviews. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . The real rejection, the real accepted write, and the real strict-mode throw below were **actually run** — not descriptions of documented behavior. See also this bank's own dedicated Proxy basics question for the general trap mechanism this answer builds on. ## 1. Why This Even Matters — A Story First A bank teller who genuinely refuses to process a withdrawal slip with an impossible amount written on it — the slip is handed back, the account balance genuinely never changes — versus a teller who processes it, and only later a manager silently voids the transaction with no receipt at all. A set trap returning `false` is the teller's real refusal; verifi

Tricky JavaScript Scenario #78: Proxy traps custom sets

The problem

Question presented to candidate: "You want an object where setting user.age to something invalid — a negative number, say — is genuinely rejected rather than silently stored. How would a Proxy's set trap do that, and what actually happens to the write if the trap says no?"

What a strong answer should cover:

📌 Interview term: a set trap's real return value IS the signal — returning true tells the engine the write genuinely succeeded; returning false tells it the write was genuinely rejected — the trap itself decides whether to actually store the value at all.
📌 Verified, not assumed: a real validating set trap genuinely rejected an invalid value (a negative age) — the real underlying value was confirmed to genuinely remain unchanged — while a valid value genuinely updated it.
📌 Interview term: the real, mode-dependent failure signal — in sloppy mode, a real rejected write (trap returns false) genuinely fails silently, with no error and no visible signal the assignment did not happen. In real strict mode, the identical rejected write genuinely throws a real TypeError ("trap returned falsish for property") — directly answering the prompt's "what happens if you return false" with a real, mode-dependent answer, not one universal behavior.
A precise answer names this as the identical real proxy-invariant-enforcement pattern verified elsewhere in this bank for a getter-only property write — JavaScript consistently treats a "this operation was refused" signal the same way across different mechanisms.
The precise, honest scope: a set trap can validate against ANY logic — a type check, a range check, a regex, even checking against other properties on the same object — verified directly with a real, working range/type validator.

Clarifying questions expected:

"Should an invalid write genuinely throw immediately (surfacing the bug loudly), or fail silently and let the caller separately check whether it actually took effect?" — directly determined by whether the actual calling code runs in strict mode, verified above as the real deciding factor.
"Does the validation logic ever need to reference OTHER properties on the same object (a cross-field validation), not just the single value being written?" — a real, genuine extension the set trap's own signature (which receives the full target object) directly supports.

Code / implementation expected: Yes — a real set trap genuinely rejecting an invalid value and genuinely accepting a valid one, plus a real, direct side-by-side of the sloppy-mode-silent versus strict-mode-throwing failure signal, is the concrete, convincing proof of exactly what returning false actually does.

proxy
tricky
real-world

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for JavaScript meta-programming and data-validation interviews. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. The real rejection, the real accepted write, and the real strict-mode throw below were actually run — not descriptions of documented behavior. See also this bank's own dedicated Proxy basics question for the general trap mechanism this answer builds on.

1. Why This Even Matters — A Story First

A bank teller who genuinely refuses to process a withdrawal slip with an impossible amount written on it — the slip is handed back, the account balance genuinely never changes — versus a teller who processes it, and only later a manager silently voids the transaction with no receipt at all. A set trap returning false is the teller's real refusal; ver

The solution is hidden so you can try first

7 min read · 8 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptA real validating set trap: genuine rejection of an invalid value, and the real mode-dependent sloppy-vs-strict failure signal