I am trying to test some code that uses web workers. I want to check that the error path works; i.e., that an onError handler correctly recovers from an exception thrown in the web worker.
The problem I'm running into is that the exception propagating out of the web worker causes it to be considered unhandled. For example, it prints in the browser's console log and causes my testing environment (a simple wrapper around Karma) to consider the test as failed.
So, How do I indicate to the browser/Karma that an exception bubbling out of a given web worker is expected, and should not be considered unhandled? I don't want it to print to the console, and I want my test to pass.
The only idea I've come up with is to wrap the web worker code in a try/catch and marshal the caught exception out via postMessage, but that requires throwing away quite a lot of information because of the need to stringify the error object (otherwise it triggers a data clone error).
Call preventDefault on the error event object given to the onError handler.
worker.onError = function(e) {
e.preventDefault(); // <-- "Hey browser, I handled it!"
...
}
Related
I'm trying to log a custom message to Sentry and I'm doing it using
Sentry.captureMessage("This is a test");
When this function is executed on my application I can see in the Dev Tools Network tab that the request is executed successfully:
And it also returns an event ID:
{"id":"b1db5de34d6048b38f76077ed1315fe9"}
The problem is that when I check the issues tab on the Sentry project, the message is nowhere to be found. There are other issues for the application but these are things like unhandled errors.
Are there some steps I need to follow to log messages from the captureMessage function? Can I just immediately go to the event since I have the event ID?
After a usually-short delay, you can get to the related issue in sentry by visiting a URL like: f"https://sentry.io/{organization_slug}/{project_slug}/events/{event_id}".
When I run code
var ws = new WebSocket("wss://mydomain.example/socket/service");
ws.addEventListener("error", function (error)
{
console.error("Got error=", error);
});
Is it possible that the WebSocket connection fails (emit error) before I can attach the event listener for the error event?
Looking at the documentation https://developer.mozilla.org/en-US/docs/Web/API/WebSocket/WebSocket I cannot see this detail documented anywhere.
According to the WHATWG spec it seems that the constructor should run the request in parallel – is there a guarantee that I can attach the error listener before any possible errors can raise?
The WebSocket constructor is run without synchronization of any kind and the connection may indeed encounter an error before the line with ws.addEventListener("error", ...); is executed! However, this is not a problem because the spec also says that in case of error, the actual error event is fired as a part of steps that must be queued as a task. In practice, this means that logically the WebSocket constructor is required to behave as if it would run an anonymous function with zero timeout which fires the error event.
So the actual error can happen before the JS code can attach the event listener but all the events (open, close, error, message) can only be fired delayed after the event loop is executed next time so the above code will always have to time attach the event handlers before the events can be fired.
See https://github.com/whatwg/websockets/issues/13#issuecomment-1039442142 for details.
I have some baffling behavior in my development environment for a ReactJS application which makes some API calls with fetch() and is bootstrapped with create-react-app
When handling the API call, I throw an error which is caught in a middleware elsewhere that wraps around every API call.
I have put console.log() in the catch() block in this middleware and confirmed it is catching all of these errors. Plus, it displays the error message correctly to the end user, and does not crash the application.
But the weird thing:
When I'm throwing an error explicitly with throw, the ReactJS error overlay pops up and shows it to me.
When, instead, the same code throws an error on the json() call (that is, the API call didn't return valid JSON), this is again caught by the same middleware and the error message is displayed the same way in the UI, but the ReactJS error overlay does NOT show up.
I even tried throwing SyntaxError explicitly to see what would happen, but in that case the error overlay does show up.
My question is, basically: is this anything to worry about? The error overlay is only functional on the development environment after all, and I'm not sure if it actually indicates that these errors will cause crashes/problems in production. I am not sure what the rules are for when it shows up or not. Is it expected that the overlay won't show up for an uncaught Json.parse() error, but will show up for everything else? When the error overlay shows up, is it anything to worry about if I can just close it and the app itself is still working correctly?
Errors in React are caught by Error Boundaries.
According to docs they can't catch errors in:
Event handlers
Asynchronous code (e.g. setTimeout or requestAnimationFrame callbacks)
Server side rendering
Errors thrown in the error boundary itself (rather than its children)
fetch() is an asynchronous code and React can't catch those errors. You should have try/catch block for async code or .catch() handler for promises to handle errors yourself (for example update React state to indicate that an error has happened and show the error message).
The documentation for a child process' error event says the following:
The 'error' event is emitted whenever:
The process could not be spawned, or
The process could not be killed, or
Sending a message to the child process failed.
See also subprocess.kill() and subprocess.send().
The first case is met presumably when the cp.spawn method fails to spawn the child process successfully.
Is the bit at the bottom suggesting that case 2 and 3 can only be met when the kill and send methods fail? For instance, if the child process fails to die by other means (like when calling process.kill), the error event would not be raised. It seems that that would be the case, but I want to confirm.
If I'm never calling kill or send, can I safely not consider those cases?
My suspicion was correct (I am fairly certain) as how would the OS be able to hook back into Node's code to raise the right event?
Searching for emit('error', in Node's child_process source shows you that it can be raised by cp.spawn, kill, send and disconnect.
If the process is killed by some other means, then that event could not get raised.
I know about the window.onerror event that triggers when exception occurs, so it works as a notifier as still we will get the error message in console.
What i want is that to display the custom message when the exception occur in application and get rid of all console red error messages.
Is there any way? using try catch in application is painfull though.
If you return true at the end of the onerror handler, the default handling (like printing to the console) should be skipped. Then, of course, you can do any custom handling you'd like.
There's some good documentation for the handler on MDN.