Exception in event handler always results in test failure #1068
Labels
Comments
|
I think this is up to you to handle exceptions thrown from event handlers. I don't remember of the top of my hat but this also depends on your testing setup. If you have a minimal, cloneable repository I can take a look since this is also relevant to testing-library/testing-library-docs#1060 |
|
Here's a minimal reproduction: https://github.com/stefee/react-testing-library-repro-1068 |
|
Here's the log output from View log output |
|
I am having this issue. Any news on this? |
|
@MatanBobi I just fixed the link, had it set as private by mistake. 🥇 |
|
@stefee sorry it took me some time to get to this. |
|
Thanks @MatanBobi. My understanding of ErrorBoundary is it's to handle errors thrown during the render critical path, not thrown from event callbacks. Is that not correct? Source: https://reactjs.org/docs/error-boundaries.html#how-about-event-handlers |
|
You are correct, but they just recommend you to catch the error inside the event handler. Once you decide not to catch it and throw it, if I'm not mistaken, it will be caught in an ErrorBoundary. |
This is not my understanding. If an error is thrown from within an event handler and is not wrapped in try/catch then the only result of this is an error log appearing in the console, just like how in regular JavaScript event callbacks in the browser will not affect execution of other code.
This will not be sent to an ErrorBoundary for the reason stated in the docs:
Note also the docs says:
This is not considered to be a requirement or recommendation by default, it's only necessary to catch errors in an event handler if you need to for showing feedback to the user or send to an external error tracker. My opinion is that React in the test environment should behave the same way as React in the browser, and so throwing an error in an event handler should not cause |
|
This was also explained by @eps1lon here #624 (comment) |
|
@eps1lon Could you consider adding a feature like this? import { render } from '@testing-library/react'
render(ui, { failIfEventHandlerThrows: false }) |
|
I just ran into this. I'm considering using https://developer.mozilla.org/en-US/docs/Web/API/reportError |
|
It would be nice to not demand that event handler have to handle exceptions (in order to get the tests to pass). I even enjoy that errors can "bubble up" all the way to the top where tools like Sentry can be informed about them and report them. This even seems like a good and unified way to do error handling. @eps1lon It would be nice if you could please reconsider you view on
Some related issues:
For now, I am using this as a workaround which seems to avoid that errors are reaching vitest |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@testing-library/reactversion: latestI'm finding that when an error is thrown from inside an
onClickhandler, the test will fail and there's no way for us to assert on the error. I feel like this might be a regression based on this conversation #624 (which seems to be aboutonClickexceptions not resulting in exceptions).The behavior I'm seeing (exception from within event handler results in unrecoverable error) means we can essentially never throw exceptions inside event handlers, since this makes it impossible for us to test the error handling of our components. This is problematic because some error tracking SDKs like DataDog RUM will treat unhandled exceptions differently to
console.error. If we are forced to catch exceptions inside event handlers and log them, rather than allowing them to become unhandled exceptions, this makes it harder to track errors.Here's an example:
In this example, we want to be able to test the "show error toast" part in our unit tests, but we can't since the
throw errwill result in a test failure regardless.Is the above considered to be bad practice, and we should be logging instead of throwing inside the
catch? Or is this an issue with the test library?The text was updated successfully, but these errors were encountered: