Promise.try Is a Necessary Primitive

I was debugging a legacy middleware last week and realized half the code was just defensive scaffolding to prevent a single input error from nuking the entire Node process. It was a nesting doll of try-catch blocks and .catch() handlers that made my eyes cross and my coffee go cold.

The "Sync/Async" Schism

JavaScript has this annoying habit of forcing us to know exactly how a function will fail before we even call it. If a function is asynchronous, we chain a .catch(). If it’s synchronous, we wrap it in a try-catch.

But what happens when you’re dealing with a function that *might* be either? Or a function that returns a Promise but throws an error synchronously before the Promise is even created?

Usually, we end up with this ugly pattern:

function wrapTask(taskFn) {
  try {
    // If taskFn throws here, we catch it
    return Promise.resolve(taskFn())
      .catch(err => {
        // If the promise rejects, we catch it here
        console.error('Async error:', err);
      });
  } catch (err) {
    // Boilerplate hell: handling the same error in two places
    console.error('Sync error:', err);
    return Promise.reject(err);
  }
}

It’s redundant, it’s noisy, and it’s prone to "oops, I forgot the outer try-catch" bugs. This is exactly where Promise.try steps in to save our sanity.

What is Promise.try?

Promise.try (which is finally making its way into the language spec) is a static method that takes a function and wraps its execution in a Promise. It doesn’t matter if the function returns a value, returns a Promise, or throws an immediate error—everything gets flattened into a single Promise chain.

Here is the "clean" version of the mess above:

function wrapTask(taskFn) {
  return Promise.try(taskFn)
    .then(result => console.log('Success:', result))
    .catch(err => console.error('Caught everything:', err));
}

Whether taskFn explodes because of a null pointer or rejects because a database query failed, the .catch() block will grab it. No extra boilerplate required.

The "Why Not Just Use Async/Await?" Argument

I hear the skeptics. "Can’t we just wrap everything in an async function?"

Yes, you can. async functions naturally wrap their contents in a Promise and turn thrown errors into rejections. But using an async IIFE (Immediately Invoked Function Expression) just to catch errors feels like using a sledgehammer to crack a nut.

Compare these two:

The Async IIFE way:

(async () => {
  return someDangerousSyncLogic();
})().catch(err => { ... });

The Promise.try way:

Promise.try(() => someDangerousSyncLogic())
  .catch(err => { ... });

The Promise.try version is more intent-revealing. It says: "I want to start a Promise chain here, and I want it to be safe from the very first line of code."

A Practical Use Case: The Configuration Loader

Imagine you have a function that loads configuration. It might read a file (async) or it might fail immediately if the file path is invalid (sync).

const loadConfig = (path) => {
  if (!path) {
    throw new Error("Path is required!"); // Synchronous throw
  }
  return fs.promises.readFile(path, 'utf8').then(JSON.parse); // Async return
};

// Without Promise.try, this might crash your app if path is null
// because the .catch() only watches the returned promise, 
// not the initial execution.
Promise.try(() => loadConfig(null))
  .then(config => console.log(config))
  .catch(err => console.error("Handled gracefully:", err.message));

If you didn't use Promise.try there, and passed null to loadConfig, the throw new Error would happen before .then() or .catch() were ever attached. Your process would hit an Uncaught Error and potentially exit.

The Performance and Compatibility Reality

Is it a performance silver bullet? No. It’s a syntax and safety primitive.

As of right now, Promise.try is a newer addition to the JavaScript ecosystem (Stage 4 in TC39). If you’re working in an older Node.js environment or targeting older browsers, you’ll need a polyfill (like core-js) or you can use the Bluebird library’s version, which has existed for years.

Actually, the fact that Bluebird users have been screaming for this in native JS for a decade should tell you how useful it is.

The Takeaway

I like code that handles the "edges" for me. Promise.try unifies the world of synchronous "oopsies" and asynchronous "failures" into a single, predictable flow.

It lets you stop worrying about whether a library function you're calling is *actually* async or just *eventually* async. If you're starting a Promise chain, start it with Promise.try. Your future self, staring at a stack trace at 2:00 AM, will probably thank you.