Assigning to a property of an object returned by Object.freeze() sometimes fails silently and sometimes throws a TypeError. What decides which one happens?

## The two halves of the answer A frozen object's data properties have `writable: false`. Any assignment goes through the object's internal `[[Set]]` method, which validates the write, refuses it, and returns `false`. That much is fixed — the write never lands, regardless of mode. What varies is what the *assignment expression* does with that `false`. The spec's evaluation of `obj.prop = value` ends with an operation that takes a "throw" flag, and that flag is the strictness of the code containing the assignment: - **sloppy mode** — the `false` is discarded, the expression evaluates to the assigned value, and execution continues. The property still holds its old value. - **strict mode** — a `TypeError` is thrown, typically worded like "Cannot assign to read only property 'x' of object". ```js const o = Object.freeze({ a: 1 }); function sloppy() { o.a = 2; return o.a; } function strict() { 'use strict'; o.a = 2; return o.a; } sloppy(); // 1 — the write vanished strict(); // TypeError ``` Note the expression's *value* is still the right-hand side in sloppy mode: `console.log(o.a = 2)` prints `2` while `o.a` remains `1`. That mismatch is what makes silent failure so confusing to debug. ## Strictness comes from the caller, not the object This is the part interviews probe. The frozen object carries no strictness of its own; the mode is a static property of the source text performing the write. In modern code that text is usually strict without anyone opting in: - **ES modules** are always strict — an `import`/`export` file needs no `'use strict'`. - **Class bodies** are always strict, including methods and static blocks. - A classic `<script>` or a CommonJS file without the directive is sloppy. So the same utility function, copied from a bundled module into an inline script, changes from throwing to swallowing. When someone reports "our frozen config is being mutated and nothing complains", the first question is which of these contexts the writing code lives in. ## The same split for `delete` Sealing and freezing both make properties non-configurable, so `delete obj.prop` fails. The reporting rule is identical: the `delete` operator evaluates to `false` in sloppy mode and throws a `TypeError` in strict mode. Code that branches on `if (delete obj.k)` is therefore a rare place where the sloppy behaviour is actually useful — everywhere else it hides the bug. ## Built-in methods can throw in both modes A useful exception: some standard-library algorithms perform a *throwing* write internally, independent of the caller's mode. `Array.prototype.push` is the canonical case — it uses the throwing form of `Set`, so pushing onto a frozen array throws a `TypeError` even from sloppy code, while a bare `arr[0] = 1` on the same array fails silently there. ```js const arr = Object.freeze([1, 2]); arr[0] = 9; // sloppy: ignored; strict: TypeError arr.push(3); // TypeError in BOTH modes ``` The rule of thumb: your own assignment syntax obeys your mode; a built-in that internally uses `CreateDataPropertyOrThrow` or a throwing `Set` obeys the spec text, not you. `Object.defineProperty` on a frozen object likewise always throws, because it is a function that reports failure by throwing rather than an assignment expression. ## Why the design is like this Sloppy-mode silence is a backward-compatibility artefact: before ES5 introduced property attributes, assignments could not fail, so ES5 kept failed writes non-throwing in existing code and made strict mode the opt-in that surfaces them. Strict mode turns roughly a dozen such silent failures — writes to non-writable properties, deletes of non-configurable ones, assignments to undeclared variables — into errors. ## Practical consequences 1. **Freeze is only a guard rail where the writers are strict.** In an all-ESM codebase, freezing exported constants converts an entire class of accidental mutation into a loud failure at the exact call site. 2. **Never assert immutability by reading back.** A test that does `frozen.a = 2; expect(frozen.a).toBe(1)` passes in sloppy mode for the wrong reason and throws in strict mode. Assert with `Object.isFrozen(obj)` instead, or wrap the write in `expect(() => { ... }).toThrow(TypeError)` under strict test files. 3. **Silent failure is worse than either alternative** when values quietly diverge from what the code appears to set. If you rely on freeze for correctness, make sure the writing code is strict — practically, that means modules.