Proper positioning of try/catch block in scenarios involving delayed async/await operations

Question

Proper positioning of try/catch block in scenarios involving delayed async/await operations

For the past six months, I have been utilizing async/await and have truly enjoyed the convenience it provides. Typically, I adhere to the traditional usage like so:

try {
  await doSomethingAsync()
}
catch (e) {}

Lately, I've delved into experimenting with not immediately awaiting in order to execute additional code before waiting for the async data, such as:

let p = doSometiongAsync()
... perform more tasks
await p;

or:

let p1 = doJob1();
let p2 = doJob2();
... engage in more synchronous activities ...
await p1;
await p2;

The dilemma arises when considering where to properly place the try/catch blocks to ensure that errors, whether synchronous or asynchronous, within the calls are caught effectively. Should the try/catch block encompass the initial function call:

try {
   let p = doSomethingAsync() 
 } catch(errors) {}
 ... undertake actions ...
 await p

Should the try block be positioned around the await statement... or possibly two separate try blocks, one for each?

 try {
    let p = doSomethingAsync()
 } catch(errors) {}
 ... carry out tasks
 try {
     await p;
 } catch (evenmoreerrors) {}

Thank you!

javascript typescript async-await

Answer 1

Answer №1

Whether you need a try/catch block around the doSomethingAsync function depends on whether it is an async function or a non-async function that returns a promise.

If it's an `async` function...

...all you need is the try/catch around the await; an async function never throws synchronously, even if there's an exception in the synchronous part of it.

For example:

async function foo() {
  // This is part of the synchronous portion
  console.log("synchronous part of foo");
  if (true) {
    throw new Error();
  }
  return new Promise(resolve => {
    resolve();
  });
}

(async () => {
  const p = foo(); // No uncaught error
  try {
    await p;
  } catch (e) {
    console.log("Caught the error");
  }
})().catch(e => {
  console.log("Failed to catch it!");
});

If it's a non-`async` function that returns a promise...

...the need for try/catch blocks depends on how the function is written. If it could throw in its synchronous code, then you'll need a try/catch there. You also need one around the await in case the promise gets rejected.

For example, failing to handle the synchronous part:

function foo() {
  // This is part of the synchronous portion
  console.log("synchronous part of foo");
  if (true) {
    throw new Error();
  }
  return new Promise(resolve => {
    resolve();
  });
}

(async () => {
  const p = foo(); // No uncaught error
  try {
    await p;
  } catch (e) {
    console.log("Caught the error");
  }
})().catch(e => {
  console.log("Failed to catch it!");
});

And an example where promise rejection isn't caught:

function foo() {
  // This is part of the synchronous portion
  console.log("synchronous part of foo");
  return new Promise((resolve, reject) => {
    reject();
  });
}

(async () => {
  try {
    const p = foo();
  } catch (e) {
    console.log("Caught the error");
  }
  await p;
})().catch(e => {
  console.log("Failed to catch it!");
});

Answer 2

Whether you need a try/catch block around the doSomethingAsync function depends on whether it is an async function or a non-async function that returns a promise.

If it's an `async` function...

...all you need is the try/catch around the await; an async function never throws synchronously, even if there's an exception in the synchronous part of it.

For example:

async function foo() {
  // This is part of the synchronous portion
  console.log("synchronous part of foo");
  if (true) {
    throw new Error();
  }
  return new Promise(resolve => {
    resolve();
  });
}

(async () => {
  const p = foo(); // No uncaught error
  try {
    await p;
  } catch (e) {
    console.log("Caught the error");
  }
})().catch(e => {
  console.log("Failed to catch it!");
});

If it's a non-`async` function that returns a promise...

...the need for try/catch blocks depends on how the function is written. If it could throw in its synchronous code, then you'll need a try/catch there. You also need one around the await in case the promise gets rejected.

For example, failing to handle the synchronous part:

function foo() {
  // This is part of the synchronous portion
  console.log("synchronous part of foo");
  if (true) {
    throw new Error();
  }
  return new Promise(resolve => {
    resolve();
  });
}

(async () => {
  const p = foo(); // No uncaught error
  try {
    await p;
  } catch (e) {
    console.log("Caught the error");
  }
})().catch(e => {
  console.log("Failed to catch it!");
});

And an example where promise rejection isn't caught:

function foo() {
  // This is part of the synchronous portion
  console.log("synchronous part of foo");
  return new Promise((resolve, reject) => {
    reject();
  });
}

(async () => {
  try {
    const p = foo();
  } catch (e) {
    console.log("Caught the error");
  }
  await p;
})().catch(e => {
  console.log("Failed to catch it!");
});

Answer 3

Answer №2

Errors can arise in both scenarios, one being in the asynchronous call result and another potentially occurring if there is logic prior to the return statement of the asynchronous call within a non-async function. The placement of the try/catch block should be determined by your specific logic requirements.

If you are certain that any potential errors will only occur during the asynchronous call itself, then it is advisable to include the try/catch block solely at the await statement.

Answer 4

Errors can arise in both scenarios, one being in the asynchronous call result and another potentially occurring if there is logic prior to the return statement of the asynchronous call within a non-async function. The placement of the try/catch block should be determined by your specific logic requirements.

If you are certain that any potential errors will only occur during the asynchronous call itself, then it is advisable to include the try/catch block solely at the await statement.

Proper positioning of try/catch block in scenarios involving delayed async/await operations

Answer №1

If it's an `async` function...

If it's a non-`async` function that returns a promise...

Answer №2

Similar questions

What are some ways to provide the find() method in JavaScript with a specific search argument?

Is there a way to trigger Material-UI SpeedDialAction onClick events only when the SpeedDial is open and clicked, not when it is hovered over?

Display HTML content in autocomplete using jQuery UI

Is Joi's existence a myth?

A guide on testing mouse clientY in React using JEST for effective testing

Managing components within an array

Disabling and enabling a link before and after an AJAX call using jQuery

Error Encountered with Nested Angular Material Tabs

The Rtk query function does not generate endpoints

Modify the code to interpret a new JSON structure

Comparing two inherited classes in Typescript: A step-by-step guide

Angular 11 is throwing an error stating that the type 'Observable<Object>' is lacking certain properties as required by its type definition

Expo's ReactNative camera feature fails to flip the camera view

Quick method to populate an array with elements

Image loading failure detected in ReactJS

Mastering the usage of Higher Order Components (HOC) with both types of props is

issue with deploying a software package and getting it installed

Issue with ng-checked not detecting boolean values retrieved from local storage

Acquiring information from file within component operation

Angular.js enables seamless synchronization between contenteditable elements and the $scope object by automatically updating the

Proper positioning of try/catch block in scenarios involving delayed async/await operations

Answer №1

If it's an async function...

If it's a non-async function that returns a promise...

Answer №2

Similar questions

What are some ways to provide the find() method in JavaScript with a specific search argument?

Is there a way to trigger Material-UI SpeedDialAction onClick events only when the SpeedDial is open and clicked, not when it is hovered over?

Display HTML content in autocomplete using jQuery UI

Is Joi's existence a myth?

A guide on testing mouse clientY in React using JEST for effective testing

Managing components within an array

Disabling and enabling a link before and after an AJAX call using jQuery

Error Encountered with Nested Angular Material Tabs

The Rtk query function does not generate endpoints

Modify the code to interpret a new JSON structure

Comparing two inherited classes in Typescript: A step-by-step guide

Angular 11 is throwing an error stating that the type 'Observable<Object>' is lacking certain properties as required by its type definition

Expo's ReactNative camera feature fails to flip the camera view

Quick method to populate an array with elements

Image loading failure detected in ReactJS

Mastering the usage of Higher Order Components (HOC) with both types of props is

issue with deploying a software package and getting it installed

Issue with ng-checked not detecting boolean values retrieved from local storage

Acquiring information from file within component operation

Angular.js enables seamless synchronization between contenteditable elements and the $scope object by automatically updating the

If it's an `async` function...

If it's a non-`async` function that returns a promise...