-
Notifications
You must be signed in to change notification settings - Fork 226
Add listeners for unhandled errors to web views #2139
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
Changes from 2 commits
7176f69
d8c2562
47fa752
969fdb6
3fe0699
64531f5
f2f1b1d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,31 @@ | ||
| import { getErrorMessage, getErrorStack } from "../../pure/helpers-pure"; | ||
| import { vscode } from "../vscode-api"; | ||
|
|
||
| const unhandledErrorListener = (event: ErrorEvent) => { | ||
| vscode.postMessage({ | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does the stack checking you implemented earlier to avoid printing stack traces for not-our-code also work for the webview? This is something to verify at least.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'll try to do a test with another extension to make sure, but I'm currently pretty confident that webviews are isolated and so the errors from one are not reported in another. I say this because the various webviews in our application are not interfering with each other. We get errors from a webview if and only if a listener has been registered in that particular view, and having another view open with a listener registered will not make it report errors from other open views. |
||
| t: "unhandledError", | ||
| error: { | ||
| message: getErrorMessage(event.error), | ||
| stack: getErrorStack(event.error), | ||
| }, | ||
| }); | ||
| }; | ||
|
|
||
| const unhandledRejectionListener = (event: PromiseRejectionEvent) => { | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should we be making a distinction between the unhandled errors and unhandled rejections? As far as I am aware, unhandled rejections don't cause any user-visible behaviour (except perhaps some data not loading), but unhandled errors might cause the complete view to disappear. It would be useful to make that distinction in the telemetry.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For now I'm going to leave them combined. I don't think it's quite as well defined as saying unhandled errors are always more important. Missing or incorrect data is also bad, and maybe worse if the user don't know the data they're looking at is incorrect. Unhandled errors can also happen outside of rendering. Also, we can certainly split these up in the future, and doing it after this PR will be fine. The telemetry is quite schema-less and we only keep it for a short period, so changing the format is quite cheap to do. |
||
| vscode.postMessage({ | ||
| t: "unhandledError", | ||
| error: { | ||
| message: getErrorMessage(event.reason), | ||
| stack: getErrorStack(event.reason), | ||
| }, | ||
| }); | ||
| }; | ||
|
|
||
| /** | ||
| * Adds listeners for unhandled errors / rejected promises. | ||
| * When an error is detected a "unhandledError" message is posted to the view. | ||
| */ | ||
| export function registerUnhandledErrorListener() { | ||
| window.addEventListener("error", unhandledErrorListener); | ||
| window.addEventListener("unhandledrejection", unhandledRejectionListener); | ||
| } | ||
Uh oh!
There was an error while loading. Please reload this page.