Review this JavaScript, where db.query(id) already returns a promise: function getUser(id) { return new Promise((resolve, reject) => { db.query(id).then(row => resolve(row), err => reject(err)); }); } — what is wrong with it, and when is new Promise actually the right tool?

## The name and the shape This is usually called the explicit promise construction antipattern (or the deferred antipattern). Its signature is a `new Promise` whose executor immediately consumes another promise and forwards its settlement. The give-away in review is simple: **if the executor body contains `.then`, `await`, or `async`, you already had a promise and did not need the constructor.** ## Why it looks harmless The code appears to work. `db.query(id)` settles, one of the two handlers runs, and the outer promise settles with the same value or reason. Callers cannot tell the difference in the happy path, which is exactly why the pattern survives code review and spreads. ## What it actually costs **1. It swallows throws.** Once `resolve(row)` has been called, the promise is settled and immutable. Any exception raised afterwards inside that handler has nowhere to go: it rejects the invisible promise created by `.then`, which nobody holds. ```js return new Promise((resolve, reject) => { db.query(id).then((row) => { resolve(row); audit(row); // if this throws, nothing observes it }, reject); }); ``` With `return db.query(id).then(...)` the same throw becomes an ordinary rejection your caller can `catch`. **2. It converts a rejection into a hang.** The rejection path is manual, so it can be forgotten. Write only `.then(row => resolve(row))` and a failing query leaves the outer promise pending *forever* — the caller awaits something that will never settle — while the inner rejection is reported separately as an unhandled rejection. The wrapper turned a clean error into a silent stall plus a confusing log line. **3. It loses identity and adds layers.** The returned promise is a plain `Promise`, not whatever `db.query` returned, so any subclass, extra methods, or instrumentation the driver attached are gone. Each layer also inserts extra microtask hops before the value reaches the caller. **4. It signals confusion.** A reviewer reads it as "the author does not trust promises to compose", and the same author usually also writes `new Promise(resolve => resolve(value))` instead of `Promise.resolve(value)`. ## The async-executor variant is worse ```js return new Promise(async (resolve) => { const row = await db.query(id); // if this rejects... resolve(row); }); ``` The `Promise` constructor ignores the executor's return value, so the promise returned by the `async` executor is discarded. A rejection inside it therefore has no handler at all, and because `resolve` was never reached, the outer promise stays pending. One line produces both an unhandled rejection and a permanent hang. ## The rewrite ```js function getUser(id) { return db.query(id); } // or, when there is genuinely more to do: async function getUser(id) { const row = await db.query(id); return toUser(row); } ``` Returning a promise from a `.then` handler or from an `async` function adopts it: the outer promise waits for the inner one and mirrors its settlement, including its rejection. That adoption is exactly what the hand-written wrapper was trying — badly — to reimplement. ## When new Promise is right Use the constructor when no promise exists yet and you must create one from a different mechanism: - an error-first callback API with no promise form; - a one-shot event or a `message`/`load`-style notification; - a timer: `new Promise(r => setTimeout(r, ms))`; - a **deferred**, where you deliberately capture `resolve` and `reject` and settle them from elsewhere — for example a request/response protocol over a socket, where a reply arrives later carrying a correlation id. ```js const pending = new Map(); function request(id, payload) { return new Promise((resolve, reject) => { pending.set(id, { resolve, reject }); socket.send({ id, payload }); }); } // elsewhere: pending.get(msg.id).resolve(msg.body) ``` That deferred is legitimate because there is no promise to adopt — the settlement genuinely arrives from another part of the program. Even then, keep the executor tiny and guarantee that every path settles exactly once. ## Spotting it in review Ask one question of every `new Promise`: *what non-promise thing is being adapted here?* If the answer names a callback, an event, or a timer, it is correct. If the answer is "another promise", delete the constructor and return the inner promise.