Discussion on: Making Await More Functional in JavaScript

View post

Your "bad" example is not very honest (the one before your section "Await catch handling"), compared to your "good" example (the one just after your section "Await catch handling").

It should be something like that:

const handleSave = async rawUserData => {
  let user;
  try {
    user = await saveUser(rawUserData);
  } catch (HTTPError as err) {
    return createToast(`User could not be saved`));
  }
  createToast(`User ${displayName(user)} has been created`);

  try {
    await postUserToMailChimp(rawUserData);
  } catch (HTTPError as err) {
    return createToast(`User could not be subscribed to mailing list`));
  }

  createToast(`User ${displayName(user)} has been subscribed`);
};

And in that case, I actually prefer it...

craig martin • Oct 11 '19

Hm, interesting. I didn't mean for it to be dishonest. I've always held return-ing inside a catch to be taboo and so didn't even consider it here. Things can get crazy (for example) if a finally clause is then attached. I can't even tell you the what the result would be between js evaluating the finally and returning the value from the catch, which is probably why I've never let myself return in a catch... but maybe I should update the example? Or maybe this adds more to the "casually dangerous" / less readable point?

Anyway, thanks for calling it out!!