What is the best way to handle errors that occur asynchronously without using promises in order to respond to those specific errors?

Question

What is the best way to handle errors that occur asynchronously without using promises in order to respond to those specific errors?

I have searched for answers but none seem to directly address my specific question.

My current usage involves the pattern shown below:

 class A
 {
     getLocation()
     {
         return Promise.reject(2222222)
     }
     async a()
     {
         try
         {
             var loc = await this.getLocation();
             alert(loc)
         }
         catch (e)
         {
             alert("catch 2")
         }
     }
 }
 new A().a();

Result : "catch 2"

Even when I introduce an error in the getLocation function :

  getLocation()
     {
         throw Error("ffffff")
     }

- I still get the same result - which is expected.

But here lies the issue:

The behavior of errors thrown asynchronously-non-promised is different:

So this code won't be caught at all:

  getLocation() //bad code from a third party code , third party code
  { 
      return new Promise((v, x) => setTimeout(() =>
      {
          throw Error("ffffff")
      }, 100))
  }

Question:

Considering that I want to capture these errors, is there a better approach?

I could simply do:

window.onerror = function () { alert(4)}

However, this would not align with the flow of .catch(...) or catch(){}, and I wouldn't be able to handle actions specifically related to the error-causing event.

Full disclosure:
This scenario is purely for educational purposes.

javascript typescript async-await es6-promise ecmascript-2017

Answer 1

Answer №1

an issue that arises asynchronously without promises can be quite tricky to handle

Avoiding this issue is crucial and should be a top priority. It's important to never include business logic (even simple tasks like accessing properties) within asynchronous non-promise callbacks as it can potentially lead to errors. For example, keep in mind that functions like `JSON.parse` can fail, trying to access a property on `null` or `undefined` can throw an error, or a loop may fail if the object being iterated is not an array with a `.length` property.

The only acceptable operations within asynchronous non-promise callbacks are `resolve`, `reject`, and possibly a function like `(err, res) => { if (err) reject(err); else resolve(res); }` for APIs with multiple arguments.

To address this issue, you can refactor problematic code snippets like:

async getLocation() {
    await new Promise(resolve => setTimeout(resolve, 100));
    throw Error("ffffff");
}

or

getLocation() {
    return new Promise(resolve => setTimeout(resolve, 100)).then(res => {
        throw Error("ffffff");
    });
}

If the faulty code belongs to a third-party library, try contacting them to fix it, submit a merge request with your solution, or consider switching to another option altogether.

Is there a more effective approach to handling this situation?

While domains in Node.js were initially introduced to address issues with uncaught asynchronous exceptions, they ultimately proved unsuccessful. Perhaps in the future, technologies like zones, which offer better support at a language level, could provide a more robust solution.

Answer 2

an issue that arises asynchronously without promises can be quite tricky to handle

Avoiding this issue is crucial and should be a top priority. It's important to never include business logic (even simple tasks like accessing properties) within asynchronous non-promise callbacks as it can potentially lead to errors. For example, keep in mind that functions like `JSON.parse` can fail, trying to access a property on `null` or `undefined` can throw an error, or a loop may fail if the object being iterated is not an array with a `.length` property.

The only acceptable operations within asynchronous non-promise callbacks are `resolve`, `reject`, and possibly a function like `(err, res) => { if (err) reject(err); else resolve(res); }` for APIs with multiple arguments.

To address this issue, you can refactor problematic code snippets like:

async getLocation() {
    await new Promise(resolve => setTimeout(resolve, 100));
    throw Error("ffffff");
}

or

getLocation() {
    return new Promise(resolve => setTimeout(resolve, 100)).then(res => {
        throw Error("ffffff");
    });
}

If the faulty code belongs to a third-party library, try contacting them to fix it, submit a merge request with your solution, or consider switching to another option altogether.

Is there a more effective approach to handling this situation?

While domains in Node.js were initially introduced to address issues with uncaught asynchronous exceptions, they ultimately proved unsuccessful. Perhaps in the future, technologies like zones, which offer better support at a language level, could provide a more robust solution.

Answer 3

Answer №2

Errors need to be captured at the exact location where they originate.

The following code snippet is flawed and requires fixing directly in the code:

getLocation() // This is bad practice from a third-party source
{ 
    return new Promise((resolve, reject) => setTimeout(() =>
    {
        throw Error("ffffff")
    }, 100))
}

If this is third-party code, it can either be forked or patched for improvement.

To globally monitor exceptions, developers can utilize the onerror method as mentioned earlier. It should solely serve as a notification tool for existing errors rather than being used to handle them conventionally.

The unhandledrejection event also serves the same purpose of notifying about unhandled promise rejections. However, it may not address errors within the given snippet since they are thrown within a setTimeout callback and do not lead to promise rejection.

Answer 4

Errors need to be captured at the exact location where they originate.

The following code snippet is flawed and requires fixing directly in the code:

getLocation() // This is bad practice from a third-party source
{ 
    return new Promise((resolve, reject) => setTimeout(() =>
    {
        throw Error("ffffff")
    }, 100))
}

If this is third-party code, it can either be forked or patched for improvement.

To globally monitor exceptions, developers can utilize the onerror method as mentioned earlier. It should solely serve as a notification tool for existing errors rather than being used to handle them conventionally.

The unhandledrejection event also serves the same purpose of notifying about unhandled promise rejections. However, it may not address errors within the given snippet since they are thrown within a setTimeout callback and do not lead to promise rejection.

Answer 5

Answer №3

Here is an example of how the basic usage would look:

class A {
  getLocation(x) {
    return new Promise((resolve, reject) => setTimeout(() => {
      // a lot of asynchronous code
      try {
        //simulating unexpected exception    
        if (x === 2) {
          throw ("code error");
        }
        if (x) {
          resolve('success');
        } else {
          reject('conditional rejection');
        }
      } catch (ex) {
        reject(ex);
      }
    }, 1000));
  }
  async a(x) {
    await this.getLocation(x).then((loc) => console.info(loc)).catch((e) => console.error(e));
  }
}
let o = new A();
o.a(2);
o.a(0);
o.a(1);

The rejection of the Promise doesn't always mean there is a code Exception, and similarly, a code Exception doesn't necessarily lead to a Promise rejection.

Answer 6

Here is an example of how the basic usage would look:

class A {
  getLocation(x) {
    return new Promise((resolve, reject) => setTimeout(() => {
      // a lot of asynchronous code
      try {
        //simulating unexpected exception    
        if (x === 2) {
          throw ("code error");
        }
        if (x) {
          resolve('success');
        } else {
          reject('conditional rejection');
        }
      } catch (ex) {
        reject(ex);
      }
    }, 1000));
  }
  async a(x) {
    await this.getLocation(x).then((loc) => console.info(loc)).catch((e) => console.error(e));
  }
}
let o = new A();
o.a(2);
o.a(0);
o.a(1);

The rejection of the Promise doesn't always mean there is a code Exception, and similarly, a code Exception doesn't necessarily lead to a Promise rejection.

What is the best way to handle errors that occur asynchronously without using promises in order to respond to those specific errors?

Answer №1

Answer №2

Answer №3

Similar questions

The function cannot be called on params.getValue()

Guide on adding JSON data from a web service whenever a function is invoked in AngularJS

Ways to effectively test public functions in Typescript when using react-testing-library

Is there a way to display the inbox area upon completion of the document loading process?

Having trouble initialising an array of objects in TypeScript? (TS1109: Expression expected)

Learn the process of showcasing database content on a webpage with an interactive feature that enables users to choose and access additional details

Error: Attempting to access the text content of a null object

Identifying geometric coordinates within Canvas

JavaScript - The function will not execute any code inside its body

Using Jquery to insert a line break in a textarea: instead of using , use ↵

What could be causing the JWT token to not be transferred to the backend API when the page is reloaded or loaded?

Setting the Content-Type of a JavaScript file within a NodeJS application

Preventing me from instantiating objects

The Firebase JQuery .on method is incrementally updating individual values in an array instead of updating them all simultaneously

Tips on redirecting the user to the page they have selected

Dynamic updating of Laravel models

What are the steps for enlarging the display containing components with the 'position: absolute' style?

Exploring the extraction of elements from list items using jQuery

How can I determine the quantity of pairs in an array using JavaScript?

What is the reason behind `tslint` flagging `TS2531: Object may be null` even though I verified its existence beforehand?