In JavaScript, what does calling an `async` function return, and how do a plain `return 42`, a `throw`, and a `return somePromise` inside its body each show up in that returned value?

## The single guarantee The `async` keyword is a promise-shaped contract on the function's *return type*. Before the body starts executing, the engine creates a promise using the built-in `Promise` constructor. That promise is what the caller receives; the body's eventual outcome only decides how it settles. So the type of `f()` is fixed at the declaration site — you can always `.then()` it, always `await` it, and you can never get a bare value out of it synchronously. ```js async function f() { return 42; } const r = f(); console.log(r); // Promise { 42 } (already fulfilled) console.log(r instanceof Promise); // true r.then(v => console.log(v)); // 42 ``` ## return fulfils A `return v` inside the body fulfils the returned promise with `v`. `return` with no value fulfils it with `undefined`, and so does falling off the end of the body. That is why an async function that only performs side effects still gives the caller something meaningful to await — a signal that the work finished. ## throw rejects A `throw` anywhere in the body — including in the synchronous stretch before the first `await` — rejects the returned promise with the thrown value. It does **not** surface as a synchronous exception at the call site. This is the trap juniors hit most: ```js async function boom() { throw new Error('nope'); } try { boom(); // no exception here } catch (e) { console.log('never runs'); } boom().catch(e => console.log('caught:', e.message)); // caught: nope ``` The rejection is a value travelling through the promise, not a stack unwind through the caller. The caller has to opt into seeing it, by awaiting the call or attaching a rejection handler. ## Returning a promise: adoption, not nesting The most commonly misstated part is `return somePromise`. People expect `Promise<Promise<T>>`. You never get that. Settling a promise runs the promise *resolution* procedure: if the resolution value is a **thenable** (any object with a callable `then` method — every promise qualifies), the outer promise does not fulfil with it. It subscribes to it and adopts its fate: fulfil with the inner value, or reject with the inner reason. ```js async function g() { return Promise.resolve('x'); } g().then(v => console.log(v, typeof v)); // x string — not a Promise async function h() { return Promise.reject(new Error('inner')); } h().catch(e => console.log(e.message)); // inner ``` The practical upshot: an async wrapper around a promise-returning call is transparent. `async function get() { return fetchThing(); }` is, from the caller's point of view, the same shape as `fetchThing()` itself. ## async with no await Adding `async` to a function that contains no `await` is not a no-op. The body still runs synchronously from start to finish when you call it — nothing defers it — but the value now arrives wrapped and any throw becomes a rejection. That is sometimes exactly what you want (a uniform promise-returning interface across a set of functions, some cheap and some not), and sometimes an accidental change in a function's error contract. ## The promise is always the built-in one Async functions construct their result with the intrinsic `Promise`. Defining an async method inside a class that `extends Promise` does not make the method hand back an instance of your subclass. If you need subclass behaviour, wrap the call explicitly. ## Why interviewers ask this It separates people who think `async` is a magic word that "makes things asynchronous" from people who know it is a return-value transform plus a suspension mechanism. Almost every downstream async bug — an unhandled rejection, a `try/catch` that catches nothing, a value logged as `Promise { <pending> }` — traces back to a candidate not holding this contract firmly in mind.