Promise.try가 이제 기준으로 새로 제공됩니다.  |  Articles  |  web.dev

이제 Promise.try가 모든 주요 브라우저 엔진에 출시되어 기준을 새로 사용할 수 있습니다.

https://web.dev/blog/promise-try-baseline?hl=ko

When I first heard that Promise.try() had been standardized, I examined it but couldn’t immediately grasp its purpose. It must have been created for some specific reason… Even if it wasn’t a groundbreaking feature, there had to be a story behind such a small addition. Even if it’s not a remarkable tale.

Today, let’s become archaeologists and explore its origins, proposal process, and implementation together.

Promise.try()

This is a new static method added to Promise’s lineup. Simply put, Promise.try(fn, …args) immediately (synchronously) executes the callback fn and returns the result wrapped in a promise. What does this mean? Let’s look at an example.

Suppose we have a function f that might be synchronous or asynchronous (let’s set aside async/await for now).

function f() {
  // Could be synchronous or asynchronous
  if (Math.random() < 0.5) {
    throw new Error("sync fail");
  }
  return Promise.reject(new Error("async fail"));
}

If f were just a synchronous function, we would handle errors like this:

try {
  f();
} catch (e) {
  console.log(e.message);
}

Conversely, if f returned a Promise, we would handle it like this:

f().catch(console.log);

But what if f could be either synchronous or asynchronous? While there aren’t many such situations, if there were, we would need to do this:

Promise.resolve().then(f).catch(console.log);

What’s the problem with this approach?
It changes when f executes. Let’s consider the event loop’s execution order. The execution flow of Promise.resolve().then(f).catch(console.log) is as follows:

1. Promise.resolve() immediately returns a promise that’s already fulfilled.
2. .then(f) registers f as an onFulfilled handler and puts the corresponding Reaction Job into the microtask queue.
3. After the current call stack is completely cleared, the event loop processes that microtask and executes f.
4. If f throws an exception synchronously, that exception is converted to a reject state of the new promise returned by .then, which the subsequent .catch receives.

Consequently, f executes in the next tick. This breaks the call stack, making debugging difficult and delaying exception propagation by one beat.

This is where Promise.try comes to the rescue.

Promise.try(f).catch(console.log);

When used this way, Promise.try immediately executes f inside itself, resolving with the value if successful or rejecting if it throws. Of course, if it’s asynchronous, it handles it asynchronously as expected. Think of it as a way to handle synchronous cases uniformly with asynchronous ones. This way, f’s execution timing isn’t delayed, and when encountering synchronous errors, execution and tracing remain in the current call stack without breaking.

But you might wonder:

First, let’s briefly review Promise’s timeline.

Promises were introduced in ES6, followed by async/await in ES2017.

Now imagine you’re a developer in that era, before async/await existed.

Suppose you need to write code that reads a file and parses it as JSON. You need to check if the file is a JSON file, parse it if it is, and throw an error if it’s not. You might write something like this:

const fs = require("fs").promises;

const readFile = (file) => {
  if (!file.endsWith(".json")) {
    throw new Error("not json");
  }
  return fs.readFile(file, "utf8");
};

This function is handled synchronously or asynchronously depending on the filename. Following the approach we examined above, it would look like this:

Promise.resolve()
  .then(() => readFile("some.json"))
  .then(JSON.parse)
  .catch(handleError);

Unnecessary elements intervene in understanding the code’s intent. resolve and then only serve to wrap things in a Promise—they’re essentially tricks.

Even back then, libraries were created to solve these kinds of problems, similar to today’s Promise.try. The Bluebird library notably allowed usage like this:

Bluebird.try(readJsonFile, "some.json").catch(handleError);

Looking at the implementation, it’s built to wrap thrown values back into promises. (The code is slightly simplified.)

// https://github.com/petkaantonov/bluebird/blob/master/src/method.js
Promise.attempt = Promise["try"] = function (fn) {
  var ret = new Promise(INTERNAL);
  ret._captureStackTrace();
  ret._pushContext();

// Synchronous call
var value = tryCatch(fn)();

// Wrap the result in a promise and return
ret._resolveFromSyncValue(value);
return ret;
};

Looking at this, Promise.try seems like a remarkably convenient method.
But have you often felt this inconvenience? I haven’t experienced it that much.

Because we have async/await. Rewriting the above code with async/await looks like this:

const readJsonFile = async (file) => {
  if (!file.endsWith('.json')) {
    throw new Error('not json');
  }
  return fs.readFile(file, 'utf8');
}

const processJsonFile = async () => {
  try {
    const data = await readFile('some.json');
    return JSON.parse(data);
  } catch (e) {
    console.log(e.message);
  }
}

This way, both synchronous and asynchronous cases can be handled identically.

Another example might be copy:

const copy = (text) => {
  return Promise.try(() => {
    if (navigator.clipboard) return navigator.clipboard.writeText(text);
    // ... some code for document.execCommand
    document.execCommand("copy");
  });
};

When clipboard is supported, it uses the Promise-returning method navigator.clipboard.writeText, and when not supported, it uses the synchronous method document.execCommand. This could be a use case. But with async/await, it can be handled more cleanly:

const copy = async (text) => {
  if (navigator.clipboard) {
    await navigator.clipboard.writeText(text);
  } else {
    // ... some code for document.execCommand
    document.execCommand("copy");
  }
};

So why did Promise.try appear only now? As mentioned above, Promise.try was proposed between Promise’s introduction and before async/await appeared. Looking at the first commit of [tc39]Proposal Promise-try, it dates back to 2016. And library-form implementations existed even earlier.

If it was proposed in 2016, why did it only appear now?

Fierce Persuasion

Let’s look at the process from Promise.try’s 2016 proposal to its final Stage 4 promotion and deployment in 2024.

Stage 1 - 2016.9~11

As mentioned above, Promise.try was proposed in 2016 by Jordan Harband(https://github.com/ljharb).\ Initially proposed for Stage 1 in September 2016, it wasn’t discussed due to other agenda items taking priority, and was seriously discussed in November of that year.

proposal-promise-try/README.md at f2c8fdca4b09305a0c2dbcf16c1339b9d1ce8a58 · tc39/proposal-promise-try · GitHub

ECMAScript Proposal, specs, and reference implementation for Promise.try - proposal-promise-try/README.md at f2c8fdca4b09305a0c2dbcf16c1339b9d1ce8a58 · tc39/proposal-promise-try

https://github.com/tc39/proposal-promise-try/blob/f2c8fdca4b09305a0c2dbcf16c1339b9d1ce8a58/README.md

The rationale at the time was the same as the examples we examined—to prevent unnecessary syntax usage for functions of unknown “color.”

The following meeting notes are cleaned up from the original meeting records.

function foo(relativeURL) {
  const absoluteURL = new URL(relativeURL, someBaseURL).href;

  return fetch(absoluteURL);
}

foo("http:0"); // Exception thrown!! Oops

function foo(relativeURL) {
  return Promise.try(() => {
    const absoluteURL = new URL(relativeURL, someBaseURL).href;

    return fetch(absoluteURL);
  });
}

function foo(relativeURL) {
  return (async () => {
    const absoluteURL = new URL(relativeURL, someBaseURL).href;

    return fetch(absoluteURL);
  })();
}

async function foo(relativeURL) {
  const absoluteURL = new URL(relativeURL, someBaseURL).href;

  return fetch(absoluteURL);
}

function foo(relativeURL) {
  return async do {
    // ?!?!?!
    var absoluteURL = new URL(relativeURL, someBaseURL).href;

    fetch(absoluteURL);
  };
}

As we saw above, strong doubts about the necessity of Promise.try were raised in that meeting.
So it remained at Stage 1, and 8 years passed.

Stage 2 - 2024.2

In February 2024, after a long time, discussion for Promise.try Stage 2 began.

To advance to Stage 2, they attempted persuasion using Promise.try related library usage, but doubts about Promise.try still remained.
Most usage was from jest, they said. Considering Jordan Harband also worked with a testing library called tape, this makes sense. From a testing library’s perspective, test callbacks could be synchronous or asynchronous, so such methods might have been necessary.

Stage 2.7 - 2024.04

After entering Stage 2, things progressed rapidly.
However, the same questions from before continued to exist. There were opinions that since Promise already has catch and finally, having try would be natural, and the general sentiment was that it would probably be useful but personally they wouldn’t use it much.

There were also opinions that it wasn’t equivalent to async IIFE. This part seems applicable to patterns we sometimes use.
While not frequent, the pattern below is sometimes used to handle async operations within effects (this is an example).
I’m also more familiar with the IIFE pattern, but cognitively, I think the latter is also quite intuitive when reading code. This discussion cited the higher transpilation cost of await syntax as justification.

// ① async IIFE pattern
useEffect(() => {
  (async () => {
    try {
      const res = await fetch("https://api.example.com/data");
      const data = await res.json();
      console.log(data);
    } catch (err) {
      console.error(err);
    }
  })();
}, []);

// ② Promise.try pattern
useEffect(() => {
  Promise.try(() => fetch("https://api.example.com/data"))
    .then((res) => res.json())
    .then(console.log)
    .catch(console.error);
}, []);

Stage 3 - 2024.06

From here, many things were agreed upon and implementation began, so it was promoted without much disagreement. Tests were merged into test262, and browsers began implementing. (test262 is what we call tests for ECMA-262.) https://github.com/tc39/test262/tree/main/test/built-ins/Promise/try

Stage 4 - 2024.10

In October 2024, it finally achieved final promotion.

How Was It Implemented?

Following the meeting notes, we’ve seen the process from proposal to final approval.
So how is the actual implementation structured? Let’s first look at the spec.

Translated, it looks like this:

For understanding spec pseudocode reading, refer to these two documents:

ECMAScript® 2026 Language Specification

No description available

https://tc39.es/ecma262/multipage/notational-conventions.html#sec-algorithm-conventions

Simply put, it takes a callback, executes it, and returns it wrapped as a Promise based on the result.

Now let’s jump to the V8 implementation. Let’s focus on the comments first.

https://source.chromium.org/chromium/chromium/src/+/main:v8/src/builtins/promise-try.tq\ https://github.com/v8/v8/blob/main/src/builtins/promise-reaction-job.tq

// Copyright 2024 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.

namespace promise {

// https://tc39.es/proposal-promise-try/#sec-promise.try
@incrementUseCounter('v8::Isolate::kPromiseTry')
transitioning javascript builtin PromiseTry(
    js-implicit context: Context, receiver: JSAny)(...arguments): JSAny {
  // 1. Let C be the this value.
  // 2. If C is not an Object, throw a TypeError exception.
  const receiver = Cast<JSReceiver>(receiver)
      otherwise ThrowTypeError(MessageTemplate::kCalledOnNonObject, 'Promise.try');

  // 3. Let promiseCapability be ? NewPromiseCapability(C).
  const capability = NewPromiseCapability(receiver, False);

  // 4. Let status be Completion(Call(callbackfn, undefined, args)).
  const callbackfn = arguments[0];
  let result: JSAny;
  try {
    if (arguments.length <= 1) {
      result = Call(context, callbackfn, Undefined);
    } else {
      const rest = NewRestArgumentsFromArguments(arguments, 1);
      result = Call(
          context, GetReflectApply(), Undefined, callbackfn, Undefined, rest);
    }
  } catch (e, _message) {
    // 5. If status is an abrupt completion, then
    //   a. Perform ? Call(promiseCapability.[[Reject]], undefined, «
    //      status.[[Value]] »).
    Call(context, UnsafeCast<Callable>(capability.reject), Undefined, e);

    // 7. Return promiseCapability.[[Promise]].
    return capability.promise;
  }

  // 6. Else,
  //   a. Perform ? Call(promiseCapability.[[Resolve]], undefined, «
  //      status.[[Value]] »).
  Call(context, UnsafeCast<Callable>(capability.resolve), Undefined, result);

  // 7. Return promiseCapability.[[Promise]].
  return capability.promise;
}

}  // namespace promise

Looking at the V8 code, you can see that the spec’s pseudocode we examined above is recorded as comments directly in the code.
Looking roughly at the code, you can see it’s implemented almost identically to the pseudocode in the comments. This code looks similar to TypeScript, but the extension is .tq. This tq is short for torque.
When I looked for the implementation, I expected to encounter C++, but what is this language called torque?

Torque

Torque is a DSL (Domain Specific Language) used only in V8.
Referring to Torque’s manual provides the answer to the above question. (https://v8.dev/docs/torque)

V8 Torque is a language that allows developers contributing to the V8 project to express changes in the VM by focusing on the intent of their changes to the VM, rather than preoccupying themselves with unrelated implementation details. The language was designed to be simple enough to make it easy to directly translate the ECMAScript specification into an implementation in V8, but powerful enough to express the low-level V8 optimization tricks in a robust way, like creating fast-paths based on tests for specific object-shapes.

V8 Torque is a language that helps developers contributing to the V8 project write VM logic by focusing on “what they want to change” rather than getting caught up in implementation details. It’s designed to be simple enough to easily translate ECMAScript specifications into V8 code, yet powerful enough to robustly express V8’s low-level optimization techniques, such as creating fast execution paths by detecting specific object shapes.

Torque’s purpose itself is to make existing implementations more human readable. It was created to express the intent of spec pseudocode as directly as possible.

Background

Early V8 had most built-in functions written in self-hosting JavaScript (a V8-specific dialect). This approach was decent, but frequently called functions with complex specifications, like Array methods, had to go through a warm-up process to become fast. So these core built-ins were directly written in architecture-specific assembly to achieve “maximum performance from the first call.” But the problem was that writing in assembly required duplicating tens of thousands of lines of code for each platform, making maintenance increasingly difficult.

In 2015, the situation changed with the introduction of the TurboFan optimization compiler. CodeStubAssembler (CSA, 2016), a C++ DSL that allowed humans to directly work with the common low-level IR used by the TurboFan backend, emerged. Thanks to this, code written once was converted to optimized assembly for all platforms, and many handwritten assembly codes could be removed.

But even CSA was difficult because humans had to write it all manually, and there were risks involved. So in 2019, the higher-level DSL Torque appeared, allowing you to almost copy ECMAScript pseudocode while having the compiler automatically generate the rest of the boilerplate and safety checks. Torque code is converted to intermediate-stage CSA C++ code, and TurboFan converts it back to machine code.

In summary, they evolved in layers: JS self-hosting → assembly fast-path → CSA (CodeStubAssembler) → Torque.

For specific details, see Tobias Tebbi’s presentation below:

So how is code implemented in torque converted?
Looking at the V8 source, there’s also a compiler for torque. https://github.com/v8/v8/blob/main/src/torque/torque-compiler.cc

Name Origin

The names of V8-related tools are mostly named after engine-related terms. Examples include Ignition, Sparkplug, TurboFan, etc. Torque also means rotational force, so it relates to engine power, but it doesn’t feel as intuitive as other names. Rather than being directly engine-related, it might be a metaphor for applying torque to twist into CSA?

Hmm

While looking for uses of Promise.try, I explored many different things. Watching it face multiple challenges during the proposal process made me feel breathless too. I hope this helped those curious about how various methods reach us.

References

1. Promise.try - MDN Web Docs
2. Promise.try() support now enabled in Chrome (web.dev)
3. TC39 Proposal - Promise.try specification
4. Original TC39 Promise.try Proposal README
5. Bluebird - Promise.try documentation
6. What is Promise.try, and why does it matter? (Joepie91’s blog)
7. GitHub - TC39 Promise.try issue discussion
8. V8 Torque documentation
9. V8 Torque Builtins documentation
10. V8 CodeStubAssembler blog post
11. Chromium Source - Promise.try implementation in Torque
12. V8 Torque Compiler source code
13. Jfokus 2020 - V8 Torque: A Typed Language to Implement JavaScript (slides)
14. Tobias Tebbi - V8 Torque: A Typed Language to Implement JavaScript (YouTube)