Early returning inside an asynchronous function

Question

Assume the scenario where you have to call an asynchronous function, but you are not really interested about success/failure situation of that function. In that case what are the pros and cons in following two patterns stated below with respect to call stack, callback queue and event loop

Pattern-1

async setSomething() {
    try {
        set(); // another async function
    } catch (err) {
        // log the error here
    }
    return true;
}

Pattern-2

async setSomething() {
    try {
        await set(); // another async function
    } catch (err) {
        // log the error here
    }
    return true;
}

CertainPerformance · Accepted Answer · 2018-11-28T05:19:53.593

1

Pattern 1 does not catch any errors that may occur during asynchronous operations in the set function - any errors will result in an unhandled Promise rejection, which should be avoided. Pattern 1 will only catch errors that occur during set's synchronous operations (such as, when setting up a fetch request), which are not likely to occur in most situations.

Example:

// open your browser's console to see the uncaught rejection

const set = () => new Promise((_, reject) => setTimeout(reject, 500));
async function setSomething() {
    try {
        set(); // another async function
    } catch (err) {
        console.log('err');
    }
    return true;
}

setSomething();

So, pattern 2 is likely preferable. If you don't care about the result of the asynchronous call, then don't await or call .then when you call setSomething().

Or, for something this simple, you might consider using Promise methods only, no async function needed:

const setSomething = () => set()
  .catch((err) => {
    // log the error here
  });

edited Nov 28 '18 at 05:19

answered Nov 28 '18 at 05:06

CertainPerformance

356,069
52
309
320

Thanks for quick response. I agree with your comment. What if I change this into a promise implementation like below `setSomething() { return new Promise((resolve) => { set() .then(() => { // log set operation success }) .catch((err) => { // log error here }); return resolve(); }) }` – thilina_hat Nov 28 '18 at 05:17
That's the [explicit promise construction antipattern](https://stackoverflow.com/questions/23803743/what-is-the-explicit-promise-construction-antipattern-and-how-do-i-avoid-it) - best to simply return the `Promise` chain instead, as in edit – CertainPerformance Nov 28 '18 at 05:20
Thanks again for your edited answer. Just to get clarified one thing, since `set()` sits on top of `setSomething()` in call-stack is there any advantage of returning early inside `setSomething()` – thilina_hat Nov 28 '18 at 05:43
Not really, call stack depth isn't something to think about except when using recursion, though I suppose you could do `set().catch(...)` *in the place of* calling `setSomething()` – CertainPerformance Nov 28 '18 at 05:46

score 0 · Answer 2 · answered Nov 28 '18 at 05:30

This answer is a rather unconventional advice to the question than an actual answer to the examples posted by OP.

not really interested about success/failure situation of that function

If the above statement is the case, then it means, the return is not dependent on the result of the async invocation.

When you're not bothered about the return of the async invocation, it's better off to not use async/await or any type of promise at all. You could just invoke the function like any other function and process with the rest of the code.

Early returning inside an asynchronous function

2 Answers2