Skip to content

Improve the error thrown when a bundle fails to load #51070

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

Closed
wants to merge 1 commit into from

Conversation

vzaidman
Copy link
Contributor

@vzaidman vzaidman commented May 2, 2025

Summary: Changelog: [General][Internal][Breaking] When a bundle is failing to load throw an error of special type.

Breaking

didCompleteNetworkResponse now throws an Error instead of throwing a string.

In dev, we use lazy bundling which allows us to re-build only the parts of the app that are changed.

However the function that loads these lazy bundles in loadBundleFromServer.js for requests that reach didCompleteNetworkResponse with an error throws a string representing the error message which makes debugging very inconvenient because it lacks stack trace and error type. Throwing strings is not a standard practice. We better throw an error in these cases so it can be handled better.

Why a special type of error?

  • As you can see in the "after", in the test plan below, even with a stack trace, it might be hard to know where this error originates from
  • Also so extra information can be added on it. Currently adding "url"
  • Also to support error handling based on the type of error

Differential Revision: D73925027

@facebook-github-bot facebook-github-bot added CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. p: Facebook Partner: Facebook Partner labels May 2, 2025
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D73925027

@vzaidman vzaidman force-pushed the export-D73925027 branch from 0f5ec61 to 5e135d2 Compare May 2, 2025 11:42
vzaidman added a commit to vzaidman/react-native that referenced this pull request May 2, 2025
Summary:

Changelog: [General][Internal][Breaking] When a bundle is failing to load throw an error of special type.

Reviewed By: hoxyq

Differential Revision: D73925027
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D73925027

Copy link

@Hardanish-Singh Hardanish-Singh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@vzaidman vzaidman force-pushed the export-D73925027 branch from 5e135d2 to d077acf Compare May 9, 2025 09:55
vzaidman added a commit to vzaidman/react-native that referenced this pull request May 9, 2025
Summary:

Changelog: [General][Internal][Breaking] When a bundle is failing to load throw an error of special type.

### Breaking
`didCompleteNetworkResponse` now throws an Error instead of throwing a string.

In dev, we use [lazy bundling](https://github.com/react-native-community/discussions-and-proposals/blob/main/proposals/0605-lazy-bundling.md#__loadbundleasync-in-metro) which allows us to re-build only the parts of the app that are changed.

However the function that loads these lazy bundles in `loadBundleFromServer.js` for requests that reach `didCompleteNetworkResponse` with an error **throws a string representing the error message** which makes debugging very inconvenient because it lacks stack trace and error type. Throwing strings is not a standard practice. We better throw an error in these cases so it can be handled better.

Why a special type of error?
* As you can see in the "after", in the test plan below, even with a stack trace, it might be hard to know where this error originates from
* Also so extra information can be added on it. Currently adding "url"
* Also to support error handling based on the type of error

Differential Revision: D73925027
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D73925027

Summary:

Changelog: [General][Internal][Breaking] When a bundle is failing to load throw an error of special type.

### Breaking
`didCompleteNetworkResponse` now throws an Error instead of throwing a string.

In dev, we use [lazy bundling](https://github.com/react-native-community/discussions-and-proposals/blob/main/proposals/0605-lazy-bundling.md#__loadbundleasync-in-metro) which allows us to re-build only the parts of the app that are changed.

However the function that loads these lazy bundles in `loadBundleFromServer.js` for requests that reach `didCompleteNetworkResponse` with an error **throws a string representing the error message** which makes debugging very inconvenient because it lacks stack trace and error type. Throwing strings is not a standard practice. We better throw an error in these cases so it can be handled better.

Why a special type of error?
* As you can see in the "after", in the test plan below, even with a stack trace, it might be hard to know where this error originates from
* Also so extra information can be added on it. Currently adding "url"
* Also to support error handling based on the type of error

Differential Revision: D73925027
@vzaidman vzaidman force-pushed the export-D73925027 branch from d077acf to 4b70b2f Compare May 9, 2025 10:46
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D73925027

@facebook-github-bot facebook-github-bot added the Merged This PR has been merged. label May 9, 2025
@facebook-github-bot
Copy link
Contributor

This pull request has been merged in 0750b5f.

@react-native-bot
Copy link
Collaborator

This pull request was successfully merged by @vzaidman in 0750b5f

When will my fix make it into a release? | How to file a pick request?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. fb-exported Merged This PR has been merged. p: Facebook Partner: Facebook Partner
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants