Sentry-laravel: Sentry reports errors while neither Handler or Channels are configured

[jonasva]

I've setup sentry-laravel: 1.01 for my new Laravel 5.8 app.

I didn't configure the error handler as described in the docs. I also didn't add Sentry to my logging channels.

I did have my DSN configured in my .env file, as part of a kind of boilerplate structure.

To my surprise I started receiving a bunch of errors in sentry that I had created writing my local app. Don't think this should be the expected behavior, as I didn't configure Sentry to send any errors.

[stayallive]

Hey @jonasva, as part of what Sentry does we also capture so called Errors. This can be for example undefined index notices (a notice is an error with the level of E_NOTICE). And also captures fatal errors like when you run out of memory in your app.

So as long as you have your DSN configured we capture those, to prevent that, do not set your DSN.

We have added a section in the docs to explain: https://docs.sentry.io/platforms/php/laravel/#local-development

[santigarcor]

@stayallive I'm having the same issue but in my unit tests, I think it shouldn't be the normal behavior, maybe you should move it to the config file so it's more transparent to us.

Edit: I noticed it's also happening in my production environment, it's reporting me an error that is being handled with a try-catch and it should not report it because I'm not saying explicitly to report that exception:

try {
    $code = $this->clientReservation->trip->code;
} catch (\Exception $e) {
    $code = null;
}

So in that case I can not remove the DSN because otherwise I won't receive the reports of real unexpected errors.

[stayallive]

@santigarcor, please don’t enable Sentry in you unit tests that will solve that issue 👌

For the second one, I’m guessing this throws an “Cannot call bla bla on null” or something like that. You cannot catch that thus it results in an fatal error which is captured by Sentry, exactly like it should, because it crashes your app.

If you want to capture that error please see: https://stackoverflow.com/a/15505936/1580028

[stayallive]

@santigarcor sorry about that, your code actually produces a “Notice: Trying to get property of non-object”. It will not error or crash, however it will tell you that your code is doing something you might not want it to.

The result of that is still null in your variable but that’s not because of your try/catch.

The notice will be caught by Sentry, although it wont’t crash your app it’s something you can fix.

If you are on PHP 7 you can do:

$variable = $object->nested->does->not->exist ?? null;

This will not trigger that notice and will default to null if the nested object does not exist / is null.

[susanBuck]

I was also confused by this when I upgraded to 1.0.0.

I want to make sure I'm understanding your explanation @stayallive -

Is it correct to say that when we invoke app('sentry')->captureException($exception); in our Laravel exception Handler, that's only there to enable capturing Exceptions thrown by Laravel?

And regardless of whether we do that, general errors/notices thrown by PHP will be logged to Sentry dependent on whether SENTRY_DSN is null or not?

My understanding aside...

It feels obscure to piggy-back on the SENTRY_DSN setting for enable/disable functionality. The obscurity is proven by the fact that I have to add a comment to my .env file to elaborate on how SENTRY_DSN is used to enable/disable.

Would it be clearer if there was a SENTRY_ENABLED setting?

[Jean85]

As one of the (main) contributors to the base SDK, I'm :-1: on implementing a global flag on the base SDK to disable Sentry. The presence of the DSN is the only flag that you need: setting it as null (or avoiding setting it altogether, since null is the default) is the only thing that you need to care about.

As for Laravel's peculiarity, it's not my area of expertise, so I leave it to @stayallive; but if I understood it correctly, the main limitation is in the fact that we cannot catch exceptions directly without a manual edit in the Laravel exception handler (maybe because it doesn't let them bubble up?); in the Symfony integration we can listen to the kernel.exception event to overcome this issue, is there anything like that in Laravel?

[marcoocram]

It don't make sense report errors when the exception is captured. I've noticed that if i put on sentry file configuration 'error_types' => ~E_ALL fix this behaviour but im not sure that this is the right solution...

[Jean85]

No it's not. Errors and exceptions are two completely different things, and silencing all the errors is basically the same as neutering half of Sentry functionality.

[stayallive]

As mentioned above Sentry captures all errors and (uncaught) exceptions. For the exceptions you add some extra code to your exception handler but for the errors (this category includes notices and deprecation warnings) you don't have to do anything.

To disable Sentry completely in for example a local environment leave the SENTRY_LARAVEL_DSN value empty in your .env file (and/or the dsn key in your config/sentry.php).

If you want to control which error types are sent you can set the following in your config/sentry.php file:

    'error_types' => E_ALL ^ E_DEPRECATED ^ E_USER_DEPRECATED,

The above _example_ will for example not report any errors of the types E_DEPRECATED & E_USER_DEPRECATED, al others are captured by default.

If you want you can disable the error reporting completely but if you do that please note that errors and exception _are_ different and you might miss an undefined variable (notice) causing unwanted behaviour in your app.