Given `function Dog(name) { this.name = name; }`, what happens if you call `Dog('Rex')` without `new`, and how does the outcome differ between sloppy mode and strict mode?

## What the call actually is `Dog('Rex')` is a plain function call. Nothing about the identifier being capitalised, or about `Dog.prototype` existing, changes that — the constructor behaviour lives entirely in the `new` operator, not in the function. So none of the construction steps happen: no object is created, no prototype link is set up, and the value of the expression is whatever the body returns. A constructor body normally returns nothing, so the expression is `undefined`. ```js function Dog(name) { this.name = name; } const d = Dog('Rex'); d; // undefined d.name; // TypeError: Cannot read properties of undefined ``` Notice where the error lands: not on the line with the mistake, but on the line that uses the result. That distance is what makes the bug annoying. ## Sloppy mode: `this` becomes the global object In non-strict ("sloppy") code, a function called with no receiver gets `this` substituted with the global object — `globalThis`. The assignment therefore succeeds, and writes a global: ```js // classic <script>, no "use strict" function Dog(name) { this.name = name; } Dog('Rex'); globalThis.name; // 'Rex' ``` Two things make this worse than a plain crash. First, state is corrupted silently: if two call sites forget `new`, the second overwrites the first, and something else reading that global name gets a value it never expected. Second, in a browser `name` is an existing property of the global object with string semantics, so the write lands somewhere real rather than in a harmless slot — the class of collision you cannot reason about locally. ## Strict mode: `this` stays `undefined` Strict mode removes the substitution. A plain call passes `undefined` as the receiver and it stays `undefined`, so the first property assignment fails immediately: ```js 'use strict'; function Dog(name) { this.name = name; } Dog('Rex'); // TypeError: Cannot set properties of undefined (setting 'name') ``` This is strictly better: the failure is loud, at the offending call, with a stack that points at the caller. It is one of the concrete reasons the mode exists. ## Which mode am I actually in? The answer changes by context, and candidates who only ever write modules often get it wrong when shown a plain script. Code inside an ES module is strict whether or not you say so. Class bodies are strict. A classic script, or a function in a CommonJS file with no directive, is sloppy unless it opts in with `'use strict'`. So the same source text can silently leak a global in one file and throw in another. ## The class case With `class Dog { constructor(name) { this.name = name; } }`, `Dog('Rex')` throws a `TypeError` saying the class constructor cannot be invoked without `new` — before any body code runs, in every mode. Classes closed this hole deliberately; it is one of the behavioural differences between a class and a constructor function, not merely a syntax difference. ## Diagnosing it in real code The symptom you usually meet first is `undefined` where an object was expected, or an instance that mysteriously fails an identity or type check. Useful moves: - Look at the assignment, not the crash site: `const x = Thing(...)` with a capitalised callee and no `new` is the tell. - In sloppy code, check for a global that appeared out of nowhere; a stray `globalThis.name`, `globalThis.id` or similar is a fingerprint of this bug. - Turn the file strict (or move it to a module) and re-run: the failure jumps from far away to the exact line. ## Preventing it Three defences, in ascending order of reliability: put the code in strict mode so the mistake fails loudly; have the function detect that it was called without construction and reject or self-correct; or use a `class`, which enforces the rule for you. A fourth option is to stop exposing a constructor at all and export a factory function that internally constructs and returns the object — then there is no `new` for a caller to forget, at the cost of giving up the constructor surface. ## Why this is asked It is a compact test of three separate pieces of knowledge at once: that `new` and not the function carries the construct behaviour, that `this` binding for a plain call differs by mode, and that a function with no `return` yields `undefined`. A candidate who can walk from the forgotten keyword to the global write to the far-away `TypeError` has a working mental model rather than a memorised rule.