Global error handler not catching unhandled promise rejection ?

Global Error: The starting value problem for a system of ordinary differential equations and the global, or true, error produced by one-step procedures are both studied. On an asymptotic global error expansion, some techniques for approximating this global error are based.

Unhandled promise rejection: When a JavaScript Promise with no rejection handler is denied, the unhandledrejection event is dispatched to the global scope of the script; normally, this is the window, but it might also be a Worker. This helps with debugging and provides fallback error handling for unforeseen circumstances.

Global error handler: Every time an error is thrown within the application, this function is called. The method has access to the error as a parameter for further processing. In this instance, a dialogue is opened to display the error message, and the error is also recorded in the browser console.

Unhandled promise: When a JavaScript Promise with no rejection handler is denied, the unhandledrejection event is dispatched to the global scope of the script; normally, this is the window, but it might also be a Worker. This helps with debugging and provides fallback error handling for unforeseen circumstances.

When an action could not be completed, usually (but not always) when a value is not of the anticipated type, the TypeError object records the error. When an operand or argument provided to a function is incompatible with the type expected by that operator or function, a TypeError may be thrown.

Callbacks made it possible to nest a lot of code, and they weren’t very good at handling errors either. The standard error-handling practice for callbacks was to make sure that any potential errors were stored in the callback function’s first parameter.

Then, in order to make sure that you treated it properly, you would have to check to see if that parameter exists. This was based on promises, and the catch function was used to handle errors. Any upstream errors are handled by the catch method, which guarantees this.

In order to capture every single instance of a rejected promise at runtime within your program, this guide will show you how to go one step further and add a global promise rejection handler.

Example 1: The ability to apply an event handler to a new, globally accessible property was introduced by browsers in 2016. Every time a promise rejection is not handled, the unhandledrejection event is triggered. You can see an example of a rejected promise that is not handled in the code below.

Javascript

const P_Example = new Promise((resolve, reject) => {
    reject('Ouch');
});

P_Example.then(() => {
    console.log(`Its GFG Portal and I'm Amarjeet`);
});

// An Unhandled Promise Rejection Error occur

Output:

Ouch

The promise created by the straightforward code sample above will always be turned down. Because there was no catch technique in place to deal with probable mistakes, an error will happen when an attempt is made to fulfill the promise. The app experienced an uncaught error as a result of this!

To the rescue: the onunhandledrejection event handler! You can offer a global failsafe that will catch all rejected promises that go unhandled by using the onunhandledrejection event handler.

Example 2: The updated code below now includes our global promise rejection handler.

Javascript

// Below function will handle unhandled promise rejections
const globalPromiseRejectionHandler = (event) => {
    console.log('Unhandled promise rejection reason: ', event.reason);
}

// we will assign handler to the corresponding global, window property
window.onunhandledrejection = globalPromiseRejectionHandler;

const myPromise = new Promise((resolve, reject) => {
    reject('Something Wrong');
});

myPromise.then(() => {
    console.log(`It's GFG Portal`);
});

Output:

Something Wrong

If supplied the second argument,.then also handles errors in promises of all types, whether it be a reject() call or an error reported in a handler (which is the error handler).

.catch should be placed precisely where we want to handle mistakes and where we are aware of how to manage them. The handler ought to examine errors (custom error classes assist) and rethrow any that are unknown.
If there is no way to correct an error, it is acceptable to not use.catch at all.