You may already know that .then() accepts two arguments:

then(onFulfilled, onRejected)

If either argument is omitted or not a function, it is replaced with an identity or, for rejection, a "thrower".

// Conceptually what `.then()` does with no arguments
.then((x) => x, (x) => { throw x; })

The second argument alone is not only equivalent to .catch(), catch is just a wrapper around .then(undefined, onRejected).

But there's an interesting difference when you specify two: then's second argument is parallel. Not that is operates at the same time, but it creates a different and separate path through the chain. The two arguments are isolated from each other.

Consider this:

// Divergent paths through the code
getUserSettings()
  .then(transformSettings, loadDefaults)
  .then(showSettingsPage)
  .catch(reportError);

Neither of these alternatives are exactly the same:

// Then first
getUserSettings()
  .then(transformSettings)
  // errors in transformSettings will trigger loadDefaults
  .catch(loadDefaults)
  .then(showSettingsPage)
  .catch(reportError);

// Catch first
getUserSettings()
  .catch(loadDefaults)
  // transformSettings will now process defaults
  .then(transformSettings)
  .then(showSettingsPage)
  .catch(reportError);

Using both arguments of .then() allows you to create truly divergent paths purely with promises.

Awaiting Alternatives

You can replicate this with async await, but it either becomes an operation spanning multiple functions, eliminating much of the benefit of async/await, or you have to use extra state to manage it.

// async replacement for action().then(a, b)
// Pass all parts to a helper
async function thenWrap(action, a, b) {
  let data;
  try {
    data = await action();
  } catch (error) {
    return b(error);
  }
  return a(data);
}

Keeping it within one function requires a little extra state to ensure we don't execute the ".then()" after the ".catch()".

async function example() {
  let data;
  let processed = false;
  try {
    data = await action();
  } catch (error) {
    data = b(error);
    processed = true;
  }
  if (!processed) {
    data = a(data);
  }
  // Do more
}

That's Settled

The async solution is a bit like how one might solve the same problem with Promise.allSettled(). Because you always execute the same .then() but you receive an array of objects that communicate success or error, you can mix the declarative functional style of promises and the imperative style of aync/await.

function settledWrap(action, a, b) {
  Promise.allSettled([action()])
  .then(([result]) => {
    if (result.status === 'fulfilled') {
      return a(result.value);
    }
    return b(result.reason);
  });
}

Conclusion

I continue to be a proponent of using promise chains over async/await particularly when it comes to structuring program flow control, as the promise chain can provide a neat abstraction away from the implementation details of the functions.

You can design your functions or program flow to never need the benefit of passing two parallel arguments to .then(), but it can be an elegant solution when you want to keep your code paths separate.