What does `Promise.try()` do and why is it better than `Promise.resolve().then(fn)`?

Q: What does `Promise.try()` do and why is it better than `Promise.resolve().then(fn)`?

**Target Audience:** Engineers preparing for JavaScript/async interviews. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Every throw and catch path below was actually run in Node. ## 1. Why This Even Matters — A Story First Calling a function directly and hoping any error gets funneled into a `.catch()` somewhere downstream is like shouting a warning INTO a mailbox and hoping the mail carrier, who only checks the mailbox later, somehow hears you in real time — the warning genuinely never reaches them, because it never actually went through the mail system at all. `Promise.try` is like genuinely putting that warning INTO an actual letter and mailing it properly — now it genuinely, reliably reaches whoever is checking the mailbox (the `.catch()`), regardless of whether the original message was delivered by shouting (a sync throw) or a normal letter (an async rejection). ## 2. The Cor

The problem

Question presented to candidate: "If a function throws SYNCHRONOUSLY (not inside any Promise), does wrapping the call in .catch() somewhere catch that error? What does Promise.try(fn) actually do differently from just calling fn() directly?"

What a strong answer should cover:

📌 Interview term: Promise.try(fn) — calls fn and returns a real Promise reflecting its outcome — verified directly: whether fn returns a plain synchronous value, throws synchronously, or itself returns a Promise (like an async function), Promise.try genuinely handles ALL THREE cases uniformly, always producing a real Promise.
📌 Interview term: the real, direct answer to the prompt — verified directly: calling a synchronously-throwing function DIRECTLY (with no Promise.try) genuinely throws IMMEDIATELY, synchronously — a .catch() attached anywhere genuinely does not catch it, since the throw happens before any Promise machinery is even involved. Promise.try(fn), by contrast, genuinely catches that same synchronous throw and converts it into a real Promise rejection, catchable normally.
📌 Interview term: Promise.resolve().then(fn)'s real limitation — a precise answer names the older workaround this method replaces: wrapping a call in Promise.resolve().then(fn) ALSO catches a synchronous throw (since it defers fn's call into a .then() callback), but genuinely adds a real, unnecessary extra microtask tick delay before fn even runs, compared to Promise.try's more direct approach.
A precise answer names that Promise.try genuinely unifies handling of synchronous AND asynchronous functions behind ONE consistent Promise-returning interface — verified directly working correctly for both a plain synchronous function and a real async function.

Clarifying questions expected:

None — this is a definitional/technical question; directly answering whether a bare synchronous throw is caught (it isn't, without Promise.try) is the strong signal.

Code / implementation expected: Yes — the direct contrast between a bare synchronous throw (uncaught by any .catch()) and Promise.try's genuinely caught, converted rejection is the clearest demonstration.

promises
es2024
error-handling

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for JavaScript/async interviews. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every throw and catch path below was actually run in Node.

1. Why This Even Matters — A Story First

Calling a function directly and hoping any error gets funneled into a .catch() somewhere downstream is like shouting a warning INTO a mailbox and hoping the mail carrier, who only checks the mailbox later, somehow hears you in real time — the warning genuinely never reaches them, because it never actually went through the mail system at all. Promise.try is like genuinely putting that warning INTO an actual letter and mailing it properly — now it genuinely, reliably reaches whoever is checking the mailbox (the .catch()), regardless of whether the original message was deliv

The solution is hidden so you can try first

6 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal proof: a bare synchronous throw genuinely escapes any .catch(), while Promise.try genuinely catches the identical throw and converts it into a real rejection