Wow! You've putted a lot of effort to document your work, which is great!

I just updated ErrorHandler to take advantage of UniversalErrorHandler.
Tests pass, with some slight updates/BC breaks. Please tell me if this is affordable or not.
Fatal error handling is still in ErrorHandler and needs "universalization", but at least for other kind of errors, this hopefully demonstrates the "Universal" prefix.
Convincing?

Tests pass, with some slight updates/BC breaks. Please tell me if the is affordable or not.

As long as you stick tohttp://symfony.com/bc all is fine :)

Just came close to the functionality provided by tracy and I'll switch back both the dev and prod error handlers.

Uncaught exceptions, OOM and other fatal errors are now handled thanks to#10941 and updates in UniversalErrorHandler. I'm quite ok with the way things a "universalized" now, but that needs reviews. Feedback welcomed.

I'll now work on reconfiguring Symfony for taking advantage of UniversalErrorHandler (last commit is a WIP).

But I have a question: I'm not comfortable with the 3 monolog channels Symfony currently has (emergency, deprecation, scream). I'd prefer having only one for php-errors. But then, should I preserve BC, ie map the old channels somewhere?

The UniversalErrorHandler is currently able to have one different logger/channel per error level, just to cope with Symfony's way of logging errors. But I'm not sure this is a best practice, so I'd prefer removing this possibility, if that's a Good Thing. Is it?

ping@Tobion@Seldaek ?

@nicolas-grekas using a separate channel for deprecations was the way found to integrate deprecations in the profiler AFAIK.

IMO emergency makes no sense because that could be on the main app channel or something with a log level set to EMERGENCY. deprecation it's good to keep it separated, and scream I am not quite sure what it is, errors that have an @ but scream was enabled or ..?

@stof it maybe was the intention, but if I read the code correctly, channel information is lost during data collection, so the code relies on a side effect, based on$log['context']['type'] === ErrorHandler::TYPE_DEPRECATION. A loose test that works but doesn't require any specific channel.
In short, the deprecation channel is not used at all.
@Seldaek you guessed, scream is for ignoring @.
From your comments, I suggest having only one channel, so that if someone wants to send php errors somewhere, they can be isolated, being an emergency, a deprecation or any other, silenced or not.

I'd prefer having only one for php-errors. But then, should I preserve BC, ie map the old channels somewhere?

Having N logger has a cost. So i'm 👎 to have a logger per php-errors by default. But indeed, if it's configurable (in a PHP way) it could be perfect.

I pushed a new iteration, the PR is ready for review, please comment.

Thanks for your feedback@lyrixx, with this PR, you should be able to plug e.g. Sentry by service configuration, no need to statically ErrorHandler::setLogger() directly anymore:
I plugged the new error handler in symfony by adding a singlephp channel, some XML and FrameworkExtension updates, with more flexible options (I believe).

I just discovered that something is missing since a long time in the configuration of the prod environment for error handling: theErrorsLoggersListener does aErrorHandler::setLogger(), butErrorHandler::register() is never called, so no logging can ever happen, except the one done by the native PHP handler.

This led me to two points:

• I think we should always callErrorHandler::register(), and useset_error_handler()'s second argument to catch only what we want to catch (thus no perf impact in prod).
• Does Symfony have recommended settings forlog_errors anderror_log ini settings? Because IMHO it could be a good idea to put native php logs inapp/logs/,if the settings are not configured.

Also, I updated the behavior of the proposed error handler for E_RECOVERABLE_ERROR and E_USER_ERROR levels: these levels are special in that they are considered fatal by the native PHP error handler, even when @-silenced. Thus, the only viable option for a user error handler is to always throw an exception for these two types, no matter the error_reporting() level nor anything else.
This strategy ensures that code paths are correct, but also that the application can continue if it decides to handle the exception.

This special behavior is an other argument for always registering the error handler, even and especially in the prod env.

This PR is ready for review/merge IMHO.
Any 👍 from deciders/mergers?

I just merged AbstractExceptionHandler back into ExceptionHandler.

except for the visibility change, I'm 👍

I'm 👍 on the ErrorHandler changes, I'm pretty confident that changes in the framework glue have been carefully reviewed by@stof

Good to me 👍

First merge 👏

It's your turn now@romainneutron ! Let's help@fabpot scale with Symfony :)

Hi@nicolas-grekas
I tried to throw an exception even for E_USER_DEPRECATED errors, but couldn't do it.

ErrorHandler::register()->throwAt(E_ALL,true);

I started to debug ErrorHandler and found this PR. I see you made the following changes

E_DEPRECATED and E_USER_DEPRECATED levels never throw.

But I really don't understand why? Could you please explain this point, or get me some post about it?
Big thanks :)

Because a deprecation should never break the execution flow: they are just notices you can ignore - and you should log if you don't want to.

Thank you,@nicolas-grekas for your faster reaction.
But I have an idea, I want to break the execution flow for not production environment. I want to force clear code. If I make PR which extends the behavior and will throw Error even for E_DEPRECATED it will be useful?

publicfunctionthrowAt($levels,$replace =false,$ignoreDeprecated =true){$prev =$this->thrownErrors;$this->thrownErrors = ($levels |E_RECOVERABLE_ERROR |E_USER_ERROR);if ($ignoreDeprecated) {$this->thrownErrors &= ~E_USER_DEPRECATED & ~E_DEPRECATED;     }//...}

I will not change behavior by default, but allow to use the wondeful feature of see that errors while development.
WDYT?
Thanks

I don't think that's the appropriate place to do so.
If you want to enforce your devs to fix deprecations, you should use the phpunit-bridge in your CI instead.