Re-throw exception to invoke the native handler when a custom handler… #421
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
looks like the build is just failing due to lint -- theres a composer task to run the cs linter which will auto fix syntax so we just need to run that |
|
I'm actually going to go ahead and fix the lint bits and get it merged in since its quick. Thanks! |
|
Thank you. Travis was having an outage earlier so I couldn't see why the build was failing (page was stuck with a loading indicator forever). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change causes captured exceptions to be propagated up to the native exception handler (re-thrown).
This behaviour is on by default and is controlled by a boolean variable passed to the
registerExceptionHandleron theErrorHandler.Right now exceptions are propagated to the existing exception handler if one exists (other than the native handler, meaning a custom function has been set using
set_exception_handler).However if no custom exception handler is set exceptions will not propagate further than Sentry's handler. In other words exceptions are captured by Sentry but not re-thrown.
Because of this change in behaviour some may consider this a breaking change so we should consider the effects of it before release.
Because right now exceptions are not re-thrown the application is allowed to continue to execute and some applications may have unfortunately become dependent on this behaviour.
Those applications will face
Uncaught Exceptionfatal errors if this change is activated for them.Related issue: #407