Handle uncaught errors thrown as strings

[chrisbreiding]

• Closes Non-cross-origin uncaught error messages are left undefined #7590

User facing changelog

• Fixed an issue where errors thrown as strings would not display correctly.

Additional details

If a user application threw an error as a string (throw 'some error' as opposed to throw new Error('some error'), an internal error Cannot read property 'split' of undefined would be displayed and the uncaught:exception event would be called with the error as a string instead of as an object with typical error properties.

How has the user experience changed?

If there is a string exception in an application, the test will now fail with the correct error. If the uncaught:exception event is being used, it will be called with an error object now, as it should.

PR Tasks

• Have tests been added/updated?
• Has the original issue been tagged with a release in ZenHub?
• N/A Has a PR for user-facing changes been opened in cypress-documentation?
• N/A Have API changes been updated in the type definitions?
• N/A Have new configuration options been added to the cypress.schema.json?

[cypress-bot]

Thanks for taking the time to open a PR!

• Create a Draft Pull Request if your PR is not ready for review. Mark the PR as Ready for Review when you're ready for a Cypress team member to review the PR.
• Become familiar with the Code Review Checklist for guidelines on coding standards and what needs to be done before a PR can be merged.

[cypress]

---

Test summary

7586 • 0 • 119 • 0

---

Run details

Project	cypress
Status	Passed
Commit	b0fc916
Started	Jun 9, 2020 2:38 PM
Ended	Jun 9, 2020 2:44 PM
Duration	06:51 💡
OS	Linux Debian - 10.1
Browser	Multiple

View run in Cypress Dashboard ➡️

---

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

[kuceb]

looks good

[jennifer-shehane]

@chrisbreiding So, I get that this does actually fix an issue with string errors.

But, I don't really see this addressing the true intent of the original issue, which was a way to listen to errors in the uncaught:exception based on the original err.message. We always mutate it, so they have to do some weird regex to recognize it and pull that out.

We did change the err.message from 4.5.0 -> 4.6.0, so it could have effected some people's regexing of it...but...I wouldn't say this is a regression per se.

This should probably be a new PR to address, but people want a way to easily ignore certain application errors - that's the request. And they're thinking just pulling out the original err.message would help.

4.5.0

4.8.0