Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-throwing error in transaction catch block will propagate transaction error again #1684

Closed
crazyones110 opened this issue Mar 9, 2023 · 3 comments · Fixed by #1716
Closed
Labels

Comments

@crazyones110
Copy link

Repro

const db = new Dexie("Test_Re_Throw_Error");
db.version(1).stores({
  friends: `
  id,
  name,
  age`,
});
db.transaction("r", ["friends"], generateError).catch(e => {
  /*
  I re-throw transaction error on purpose, in my real code,
  it's like this: throw new CustomError(e)
  for clearer identification
  */
  throw new Error("throw again");
}).catch(e => {
  console.log("outermost error", e);
});

async function generateError() {
  await Promise.reject("inner error");
}

image
It's weird that throw again error was caught but inner error was exposed unexpectedly.

Dexie Version

3.2.1

@dfahlander
Copy link
Collaborator

I copied and pasted your repro into a jsfiddle but I get what was expected, the "throw again" error.

https://jsfiddle.net/nwufgymd/

@crazyones110
Copy link
Author

crazyones110 commented Mar 9, 2023

@dfahlander Well, the unhandledrejection seemed to be swallowed by sandbox environment.
I have added an unhandledrejection event handler to illustrate. https://jsfiddle.net/r0hkocL5/
Or you can start your local dev environment to see exactly my screenshot showed.

@dfahlander
Copy link
Collaborator

I see. The code behaves as expected in terms of what code paths are visited but the problematic thing is that unhandledrejection gets fired even though you are catching the error. The problem origins from the custom propagation to unhandledrejection that we do for legacy reasons (such as supporting Internet Explorer). I'll see what we can do fix it and whether it would be ok now in Dexie 4.0 to remove that custom propagation of unhandledrejection as it can generate undesired and inaccurate noise in the debugging experience.

Not to self: Check if we can remove our custom unhandledrejection propagation in the promise module and rely on the native unhandledrejection to do its job.

@dfahlander dfahlander added the bug label Mar 10, 2023
dfahlander added a commit that referenced this issue May 8, 2023
The custom unhandledrejection event propagation is not reliable when native async function throw errors. The event is fired before we have a chance to detect that the error was indeed handled in a later tick.

User code should not rely on unhandledrejection anyway but have it as a debugging tool rather - to detect errors in the code where promises aren't caught properly. Users that use async functions will get the native unhandledrejection functionality anyway, but those who still use promise-based .then()/ .catch() might not get this warning anymore after this commit. However, I believe it's better to not warn when the warning is not correct anyway.

Related issues:
* #1706
* #1689
* #934

Resolves #1684
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants