In a JavaScript constructor function invoked with `new`, what happens if the function body explicitly returns an object, and what happens if it returns a primitive such as 42 or null?

## The mechanism Calling a function with `new` invokes its `[[Construct]]` internal method, which does roughly four things: create a fresh ordinary object whose `[[Prototype]]` is the constructor's `.prototype` property, call the function body with `this` bound to that object, look at the value the body returned, and decide what the whole `new` expression evaluates to. That last step is the rule this question is about. The specification says: if the body's return value is an **Object**, return that value; otherwise return the `this` that was created. There is no merging, no unwrapping, no error. ```js function Widget(name) { this.name = name; return { name: 'replacement' }; } new Widget('original').name; // 'replacement' ``` ## "Object" means the spec's Object type An object here is anything whose specification type is Object: a plain object literal, an array, a function, a `Date`, a `Map`, a `Promise`, a boxed `new Number(1)`. All of them override `this`. Everything else is a primitive and is discarded: numbers, strings, booleans, symbols, bigints, `undefined`, and - the classic trap - `null`. ```js function Gizmo(name) { this.name = name; return null; } new Gizmo('original').name; // 'original' ``` `typeof null` famously reports `'object'`, a bug preserved from the first JavaScript engine for compatibility, but the language's own Type() operation classifies `null` as Null. `new` follows the spec, not `typeof`, so `return null` behaves exactly like `return 42` or falling off the end of the function. A subtle relative: `return new Number(42)` *does* override `this`, because that is a wrapper object, not a primitive. Interviewers occasionally use that pair to check whether you understand the boundary rather than memorised "numbers are ignored". ## The body still runs When an object return overrides `this`, the discarded object was still created and still mutated. Every statement executed, every side effect landed, and any reference you leaked out of the constructor (`registry.push(this)`) still points at the abandoned object. Only the *result of the `new` expression* changes. The abandoned object is then unreachable and collected. This matters for a real bug shape: a constructor that registers `this` somewhere and then returns a wrapper leaves the registry holding the wrong object. ## The returned object is not an instance The prototype link is established on the object `new` created, not on whatever you return. A plain object literal inherits from `Object.prototype`, so: ```js function Widget() { return {}; } new Widget() instanceof Widget; // false new Widget().someProtoMethod; // undefined ``` If you want the override *and* a working instance, build the replacement from the right prototype yourself - `Object.create(Widget.prototype)` - or return an object that was itself produced by that constructor. This is why the override rule is a foot-gun in ordinary code and a deliberate tool only in narrow cases. ## Where the rule is used on purpose Three recurring uses: - **Instance caching / single-instance objects.** The constructor stashes its first instance and returns it on later calls, so every `new` yields the same object. - **Returning a different shape than the class implies.** A constructor that returns a `Proxy` wrapping the real instance, so property access can be intercepted while callers keep writing `new Thing()`. - **Defensive factories.** Older code wrote `function Foo(){ if (!(this instanceof Foo)) return new Foo(); ... }` so the function works with or without `new` - the recursive call returns an object, which overrides whatever `this` happened to be. ## Classes obey the same rule `class` constructors are constructors, so a base class behaves identically: return an object and it replaces the instance; return a primitive and it is ignored. Derived classes (those written with `extends`) are the one place the rules tighten - returning a non-`undefined` primitive there is an error rather than a no-op. ## How it is probed The question almost always arrives as a "what does this print" puzzle with two or three constructors side by side - one returning an object, one returning a number, one returning `null`. The strong answer names the object-vs-primitive split, correctly classifies `null` as a primitive for this purpose, and adds that the override object does not inherit from `Fn.prototype`. The weak answer guesses that returns from constructors are always ignored, or that the returned value is merged with `this`.