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

Catching errors from an RCTRootView #1086

Closed
ide opened this Issue May 1, 2015 · 3 comments

Comments

Projects
None yet
3 participants
@ide
Collaborator

ide commented May 1, 2015

I want to be able to conceptually catch all errors thrown from an RCTRootView instance rather than displaying the red box. This opens the door for custom error handling and the red box could be implemented as the fallback error handler.

@nicklockwood

This comment has been minimized.

Show comment
Hide comment
@nicklockwood

nicklockwood May 1, 2015

Contributor

You can add a custom error handler by using RCTSetLogFunction(). This won't disable the RedBox (perhaps it should - TBD), however you can do that separately by setting RCT_DEBUG=0.

If you can think of a better solution that won't break existing expectations, I'd be happy to consider it.

In future, RCTRedBox is likely to become a module, so you'll be able to replace it by passing in an alternative module with the same name vis the moduleProvider block. For now, the only option that doesn't involve changing the RCT_DEBUG preprocessor flag would be to swizzle some methods in the RCTRedBox (we do this in some of our unit tests).

Contributor

nicklockwood commented May 1, 2015

You can add a custom error handler by using RCTSetLogFunction(). This won't disable the RedBox (perhaps it should - TBD), however you can do that separately by setting RCT_DEBUG=0.

If you can think of a better solution that won't break existing expectations, I'd be happy to consider it.

In future, RCTRedBox is likely to become a module, so you'll be able to replace it by passing in an alternative module with the same name vis the moduleProvider block. For now, the only option that doesn't involve changing the RCT_DEBUG preprocessor flag would be to swizzle some methods in the RCTRedBox (we do this in some of our unit tests).

@ide

This comment has been minimized.

Show comment
Hide comment
@ide

ide May 5, 2015

Collaborator

Thanks for the tip about RCTSetLogFunction(). I want to build a sort of custom console for the RCTRootView so this sounds great to start.

Collaborator

ide commented May 5, 2015

Thanks for the tip about RCTSetLogFunction(). I want to build a sort of custom console for the RCTRootView so this sounds great to start.

@ide

This comment has been minimized.

Show comment
Hide comment
@ide

ide May 27, 2015

Collaborator

Handling soft/hard exceptions with the exceptions manager works well for most cases. I think there are some errors that don't go through that code path but will open up separate issues and/or PRs for those when needed.

Collaborator

ide commented May 27, 2015

Handling soft/hard exceptions with the exceptions manager works well for most cases. I think there are some errors that don't go through that code path but will open up separate issues and/or PRs for those when needed.

@ide ide closed this May 27, 2015

@facebook facebook locked as resolved and limited conversation to collaborators May 29, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.