Skip to content
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

[Fiber] Preserve "Break on all/uncaught exceptions" behavior in DEV mode #8961

Merged
merged 4 commits into from
Feb 25, 2017

Conversation

acdlite
Copy link
Collaborator

@acdlite acdlite commented Feb 8, 2017

  • Refactor invokeGuardedCallback so that it returns a thrown error. Need this for Fiber's error handling.
  • Use invokeGuardedCallback in place of Fiber's try/catch blocks.
  • Test behavior in browsers:
    • Chrome
    • Firefox
    • Safari
    • Edge
  • Figure out how to deal with ErrorUtils shimming (see D4538250)

};
var evtType = `react-${name}`;
const evtType = 'react-' + (name ? name : 'invokeguardedcallback');
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Is the name argument worth keeping?

} catch (error) {
let error;
if (__DEV__) {
error = invokeGuardedCallback('commitphase1', commitAllHostEffects, null, finishedWork);
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'm guessing the name parameter is only important for ErrorUtils. I'll come back to this before landing.

Copy link
Collaborator

Choose a reason for hiding this comment

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

yea but I'm not sure we need this feature from ErrorUtils neither. Maybe for event handlers I guess it is pretty useful.

@acdlite acdlite changed the title [WIP][Fiber] Preserve "Break on all/uncaught exceptions" behavior in DEV mode [Fiber] Preserve "Break on all/uncaught exceptions" behavior in DEV mode Feb 9, 2017
@acdlite
Copy link
Collaborator Author

acdlite commented Feb 9, 2017

@sebmarkbage Ready for review

Copy link
Collaborator

@sebmarkbage sebmarkbage left a comment

Choose a reason for hiding this comment

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

I'm not too happy with how invokeGuardedCallback gets optimized, even with a compiler. It probably won't be able to strip out the array slicing etc.

Can we reorganize our callers so that they use try/catch locally in a prod mode so that the local stack frame optimizations can do the best they can? Even if try/catch deopts the function in some VMs.

And then we only invoke invokeGuardedCallback if we're in DEV mode.

@acdlite acdlite dismissed sebmarkbage’s stale review February 22, 2017 22:29

Updated to use a local try-catch when not in DEV

}
}
if (refError !== null) {
captureError(current, refError);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we move this into the try/catch and only do the if (ref !== null) for the __DEV__ case?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Fixed

}

var ReactErrorUtils = {
invokeGuardedCallback: invokeGuardedCallback,
invokeGuardedCallback,
invokeGuardedCallbackProd: invokeGuardedCallback,
Copy link
Collaborator

Choose a reason for hiding this comment

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

Can we avoid exposing this since we're not using it? Waste of bytes.

We can use this more flexible version for error handling in Fiber.

The DEV mode version uses same fake event trick as before to preserve
"break on uncaught exception" behavior when debugging.
Added a guard in the global error event listener to prevent nested
errors from being captured higher up the stack.

Also found a bug where the DEV version of invokeGuardedCallback would
infinite loop if there were nested invocations with the same name. Fixed
by appending the depth to the fake event name. (I'm actually not sure
why this is necessary.)
Only in DEV. In production, continue using a local try-catch.
We weren't using it anywhere except for the test suite. Instead, we can
change the environment flag and run the tests in both environments.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants