Fatal errors are not handled anymore since release 0.19.0

[ghost]

Since the Raven_Breadcrumbs_ErrorHandler is being registered as error handler (e988712), fatal errors are not handled anymore. When a fatal error occurs, I get a blank screen instead and nothing is sent to Sentry. When I disable the call of $this->registerDefaultBreadcrumbHandlers() in the constructor of Raven_Client, everything works fine again (fatal errors are then handled by Symfony\Component\Debug\ErrorHandler::handleFatalError()). However, using Symfony and Monolog there is no possibility to set the option install_default_breadcrumb_handlers to false in the config.

My Monolog config:

monolog:
    handlers:
        main:
            type:          fingers_crossed
            action_level:  notice
            handler:       sentry
            excluded_404s:
                - ^/
        sentry:
            type:          raven
            level:         notice
            dsn:           "%raven_sentry_dsn%"

I'm using Symfony 3.1.2 with Monolog 1.20.0 and monolog-bundle 2.11.1.

[ghost]

(Issue posted using the wrong account, no possibility to fix this.)

[dcramer]

So a couple things:

• We should make sure options like this are exposed via sentry-symfony. Ideally these optiosn can be dynamic, though I'm not entirely sure we can do that with Symfony easily.
• It sounds like something might be being clever (either us, or Symfony) and not bubbling up errors when another handler is present. We'll need to investigate that further to determine why.

[dcramer]

Just to update this, we need more information to reproduce.

There's a few important things here:

1. We dont suggest using Monolog as an integration endpoint. It's a legacy means of support, and was deprecated since we launched sentry-symfony and sentry-laravel.
2. We have a sentry-symfony extension which also includes a fully functioning Q&A/demo app which there don't seem to be any issues.

[dcramer]

One last update.

The only thing I can think of here is Monolog is doing something to try and find an existing handler, and when it's present it's not registering its own. Our breadcrumb logger does the bare minimum:

$this->existingHandler = set_error_handler(array($this, 'handleError'), E_ALL);

if ($this->existingHandler !== null) {
        return call_user_func($this->existingHandler, $code, $message, $file, $line, $context);
}

So for starters I would suggest switching to sentry-symfony, but beyond that I can't explain how this could happen.

[mitsuhiko]

I changed the title since this appears to be an issue with the monolog raven handler / monolog.

[ghost]

Actually, I don't think this is only happening when using Monolog. Also Symfony's default error handler decides not to handle fatal errors when another handler is active, see the following code in Symfony\Component\Debug\ErrorHandler:

public static function handleFatalError(array $error = null)
{
    ...

    $handler = set_error_handler('var_dump');
    $handler = is_array($handler) ? $handler[0] : null;
    restore_error_handler();

    if (!$handler instanceof self) {
        return;
    }

[dcramer]

I think we're going to have to at very least not configure handlers when no DSN is set. This is slightly awkward behavior, as our goal is always to traverse the same paths of code in development (when possible) as production. This also means that if you didn't set the DSN when e.g. calling install(), and you set it later, you'd have to re-call install.

Maybe in Symfony's case it'd make sense for us to have our ErrorHandler inherit from theres?

[luxifer]

I have the same problem but with registerExceptionHandler. Exceptions that are not triggered by the Raven_ErrorHandler are not caught by the exception handler. I'll investigate this issue when I have more time.

[Jean85]

With sentry-symfony, you can avoid registering of the handler by not setting the DSN. If this is issue is still applicable, please comment further. Closing for now.