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

E_NOTICE and E_DEPRECATED / E_USER_DEPRECATED are no longer reported #318

Closed
ruudk opened this issue Feb 5, 2020 · 8 comments
Closed

E_NOTICE and E_DEPRECATED / E_USER_DEPRECATED are no longer reported #318

ruudk opened this issue Feb 5, 2020 · 8 comments

Comments

@ruudk
Copy link
Contributor

ruudk commented Feb 5, 2020

Every since upgrading to Sentry V3 I notice that we no longer get E_NOTICE and E_DEPRECATED / E_USER_DEPRECATED in Sentry.

Did something change? Do I manually need to enable this somewhere? Or did this never work and am I confused?

@Jean85
Copy link
Contributor

Jean85 commented Feb 7, 2020

This may depend on the error_types option of the base client, but it's default value is E_ALL. Another possibility is the fact that with the bundle we do not use the base client error handler but we rely on the framework's listeners, so maybe that's the culprit?

@ruudk
Copy link
Contributor Author

ruudk commented Feb 7, 2020

I think that's the issue indeed. I didn't specify or change the error types. When I check the code from this bundle, I see it only tapping into kernel errors.

@Jean85
Copy link
Contributor

Jean85 commented Feb 7, 2020

The problem here is that I had to ditch the error handler approach because it collided a lot with Symfony's error handler. This seems to be a side effect of that choice, but I would prefer not to revert to the old approach due to those issues.

Any suggestions?

@ruudk
Copy link
Contributor Author

ruudk commented Feb 7, 2020

What about registering the old handler but only for things that are not handled by Symfony?

@Jean85
Copy link
Contributor

Jean85 commented Feb 7, 2020

Right now the rergistration is done with the ErrorListenerIntegration, and it's bound to the error_types option. I thought to get that value and filter out every kind of error that is already handled by the listeners, but that option is exposed to the user, so changing that would create a strange behavior, if not a BC...

@Jean85
Copy link
Contributor

Jean85 commented Jan 21, 2021

Closing this for inactivity. Feel free to reopen/reply further if needed.

@Jean85 Jean85 closed this as completed Jan 21, 2021
@ruudk
Copy link
Contributor Author

ruudk commented Jan 21, 2021

I think this is still a valid issue or did something change regarding this?

@Jean85
Copy link
Contributor

Jean85 commented Jan 21, 2021

#322 surely changed how we handle that stuff. Also, 4.0 got released in the meantime, so that changed some stuff on the integrations too. Please report back if this is still applicable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants