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

Pass RGBA color code from JavaScript to Laravel controller

Utilizing v-model for dynamic binding within a v-for iteration

Enhancing the Performance of jQuery Scripts

Using ES6 to generate objects within other objects

Ways to retrieve the current URL in Next.js without relying on window.location.href or React Router

Sending JSON Data with Javascript Post Request

Synchronous execution following a Node.js for loop integrated with callbacks

Default Selection Issue with Radio Buttons in AngularJS

Having trouble with Vue Router view not functioning properly in my Laravel Blade page

Setting up an inline style @Input in Angular 2: A step-by-step guide

What is the best way to save an integer in HTML's localStorage instead of a string?

Refrain from showing content beneath a certain element

The Gatsby + Typescript project is reporting that the module with the name "*.module.scss" does not have any exported members

Autocomplete Data Origin

Guide on incorporating pinching gestures for zooming in and out using JavaScript

Avoid Refreshing the Page When Pressing the Like Button

Error: Unspecified process.env property when using dotenv and node.js

Developing Java-based Ajax scripts

React components featuring Material UI icons

Multiple asynchronous calls in Angular 2

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

Pass RGBA color code from JavaScript to Laravel controller

Utilizing v-model for dynamic binding within a v-for iteration

Enhancing the Performance of jQuery Scripts

Using ES6 to generate objects within other objects

Ways to retrieve the current URL in Next.js without relying on window.location.href or React Router

Sending JSON Data with Javascript Post Request

Synchronous execution following a Node.js for loop integrated with callbacks

Default Selection Issue with Radio Buttons in AngularJS

Having trouble with Vue Router view not functioning properly in my Laravel Blade page

Setting up an inline style @Input in Angular 2: A step-by-step guide

What is the best way to save an integer in HTML's localStorage instead of a string?

Refrain from showing content beneath a certain element

The Gatsby + Typescript project is reporting that the module with the name "*.module.scss" does not have any exported members

Autocomplete Data Origin

Guide on incorporating pinching gestures for zooming in and out using JavaScript

Avoid Refreshing the Page When Pressing the Like Button

Error: Unspecified process.env property when using dotenv and node.js

Developing Java-based Ajax scripts

React components featuring Material UI icons

Multiple asynchronous calls in Angular 2

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

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