Exception handler and logging channel - exception logged twice

[arxeiss]

I have Laravel 5.7 and Sentry 1.9.2 and Sentry-Laravel 0.10 I configured it as shown in Readme, but if there is some unhandled exception, in Sentry is logged as 2 events.

I think the problem is, that in my ExceptionHandler is this:

if (app()->bound('sentry') && $this->shouldReport($exception)) {
    app('sentry')->captureException($exception);
}

and in config/logging.php this:

'stack' => [
    'driver' => 'stack',
    'channels' => ['daily', 'sentry'],
],
'sentry' => [
    'driver' => 'sentry',
    'level' => \Monolog\Logger::DEBUG,
],

So if unhandled exception is thrown, it is caught by ExceptionHandler which sends it to stack which is default and also to Sentry. Is there a way how to prevent those behaviour?

I don't want to remove sentry from config/logging.php because I use Log::warning() etc a lot. And I don't want to go through all my code and pass there different channel.

[stayallive]

Hey @arxeiss,

I think the easiest would be to do something like:

    public function report(Exception $exception)
    {
        if ($this->shouldReport($exception) && app()->bound('sentry')) {
            app('sentry')->captureException($exception);
+
+           return;
        }

        parent::report($exception);
    }

The parent::report() only pushes the exception to the logger, so skipping that step will prevent it from being logged to the stack driver or the log files.

[arxeiss]

What this will do, if Sentry DNS is empty? According to #104 it looks, that Sentry will be loaded and it will not log error somewhere. Just disappear..

[stayallive]

Correct, good catch.

There is a change coming to the sentry-php package to not set or return an error id if the event is not sent (for synchronous event sending), so once that is released you can leverage that.

You can also check there if an DSN is set in you application and act accordingly.

I'm not seeing much other options since it can always happen the transport to Sentry fails for some reason... there is also not a good way to "identify" exceptions and internally check if they we're already sent by the normal integration or through a log channel.

You can always fix the log channels to correctly do what you want ofcourse 👍 that will make sure it's always correctly routed.

---

Scratch all the above actually, since you are already logging to Sentry though the log channel... why not keep it that way and just remove the captureException call from the report handler? It will be reported through the log channel only :)

[arxeiss]

@stayallive that exactly why I asked this question. Maybe I can mention it directly.

I wasn't sure if logging via channel is the same as logging via app('sentry')->captureException($exception);. So I wasn't sure if I can remove it. But now I know, that I can.

Maybe it would be nice to mention this also in Readme, that this piece of code is not mandatory, if logging is done via channels

[korridor]

@stayallive I have the same problem, but I am using Laravel 8 and sentry 2.3.1.

Is using the log driver and app('sentry')->captureException($exception); really the same? Because in my case the exception was reported twice to sentry and they look different in the sentry dashboard. For example the exception that was sent with the logging driver has the stack trace as a text as well. That's not a problem I just want to make sure that those two options have the same features before I switch to just using the log driver.

If those two options are not the same, is there any other solution that reports exceptions with captureException() and also tracks the Log::error('...') messages?

[stayallive]

No they are slightly different @korridor, the log channels use Monolog in the background and there are some differences in how errors are captured and reported and what information is available to us.

The Laravel logger stack driver has a ignore_exceptions config option we could potentially also add to our logger so you are able to use the logger for logs but, well, ignore the exception and handle those separately.

Could you maybe open up a new issue so we can track this feature request (or maybe even with a better idea if you have one?).

[chimit]

@stayallive is the Sentry exception handler any better than the Sentry as a log channel? What are the differences in the outcomes? It just looks like Sentry as a log channel is more Laravel-way.

[stayallive]

@chimit Sentry is not a logging platform. So the log channel makes less sense since that has the potential to log each and every log event from your application to Sentry for which it is not intended. The exception handler also tries to take in account if the exception was "handled" (catched) or not which the log channel doesn't do. I also personally feel like the error handler way is more Laravel-ish, but that is more a matter of opinion of course 😄

This is a very old issue so if you have follow up questions please open a new issue or come chat with us in discord in the #PHP channel.