If a deprecation error is triggered by application, this is not caught by Laravel exception handler. Here sits the logic where we determine if we send or not the error to sentry. But instead the error sent to sentry anyway.
SENTRY_LARAVEL_DSN in .envroutes.php and add the following inRoute::get('/', function () {
@trigger_error('Error!', E_USER_DEPRECATED);
return view('welcome');
});
At this point, an error is sent to sentry even if we didn't added in exception handler:
if (app()->bound('sentry') && $this->shouldReport($exception)) {
app('sentry')->captureException($exception);
}
Thanks
One more note: The above doesn't happen on [email protected]
This is due to the fact that by default the SDK is set to catch E_ALL: https://github.com/getsentry/sentry-php/blob/2.0.0/src/Options.php#L673
You need to lower that in your options if you're not interested in that level of errors. But I'm not sure why previous versions didn't do the same... The base SDK didn't had a different previous default.
Exactly as @Jean85 mentioned this is the case.
You can set the following in your config/sentry.php to for example exclude deprecations:
'error_types' => E_ALL ^ E_DEPRECATED,
Probably the reason 0.11 didn't report this is because we load much sooner now and are thus are capturing more errors happening in the initialization of the framework/packages.
Also trigger_error triggers an error and not an Exception which are very different, you can't actually "catch" errors thus they never pass through the ExceptionHandler.
I was under impression that the only place from where a message is sent to sentry is the ExceptionHandler.
Probably the reason 0.11 didn't report this is because we load much sooner now and are thus are capturing more errors happening in the initialisation of the framework/packages.
How we can stop this on development, because as long as you have SENTRY_LARAVEL_DSN in .env a message will be sent to sentry and can't be stopped.
Maybe loading later as on v.0.11 will help?
@ionutantohi don't set SENTRY_LARAVEL_DSN in your .env for development!? 馃槃
And no Sentry captures uncaught exceptions (through the snippet in the Laravel Exception Handler) and also captures PHP errors and fatal errors (for example memory limit reached) and does that automatically as soon as Sentry is registered by the Laravel integration service provider.
Hi @stayallive
I tried adding 'error_types' => E_ALL ^ E_DEPRECATED, in config/sentry.php but with no success. The error is still sent to sentry.
I think this issue is similar to #201. It seems that sentry is catching and sending suppressed errors
Thanks
Ionut
@ionutantohi Until you mentioned #201 totally missed the @ in your code example, sorry about that!
Can you tell me on what OS and/or container you are running?
You didn't missed it. I did, by not adding it when I created the issue. I have edited the issue a few minutes ago. Sorry about this.
Oh, okay awesome! Thanks for letting me know, will try to reproduce!
Hey guys!
I was having the same issues in the past few days and they were driving me nuts!. Sentry was logging errors not caught by Laravel's exception handler related to unserializable data when I tried to manually log an user out (with a remember token set) and other user's deprecated exceptions like this one briannesbitt/Carbon#1631
My report() method:
public function report(Exception $exception)
{
// Sentry Error Reporting only for staging and production environments
if (app()->environment(['staging', 'production'])) {
if (app()->bound('sentry') && $this->shouldReport($exception)) {
app('sentry')->captureException($exception);
}
}
parent::report($exception);
}
The logged errors were appearing in Sentry under the local environment tab =/
After some digging, I ended up adding the following line in `config/sentry.php`` and the reported errors were gone.
'error_types' => E_ALL & ~E_NOTICE & ~E_USER_DEPRECATED,
E_NOTICE will still be sent to Sentry if it's caught by Laravel's Exception handler and assuming you are capturing it with Sentry.
Just a little workaround until the culprit is found!
The silenced errors issue will be solved in the main SDK with getsentry/sentry-php#785
This has been fixed in 2.0.1 of the base SDK (sentry/sentry) that was just released, running composer update should pull that in and fix this issue.
A new option has been added (capture_silenced_error) to configure whether suppressed errors should be captured by Sentry and by default this is off.