I see people prefix deprecation warnings with an at sign here and there. It looks like this:
@trigger_error('This method is deprecated', E_USER_DEPRECATED);
Meanwhile it is know that @ operator will basically make any error messages go away. So it seems like these warnings do nothing, and indeed they cause no output.
@trigger_error('No one ever sees this', E_USER_DEPRECATED);
trigger_error('Visible deprecation warning', E_USER_DEPRECATED);
So, considering a quite widespread use (1, 2, 3, 4, 5 ...), why would anyone want to do that? Why would I do that? Should I follow the same approach for any deprecations?
More to the problem, there isn't an explanation I could find in Google, yet. It appears somehow related to Symfony's error handling, and there's this extensive discussion on that subject, yet I couldn't find a definite answer so far.
Quoting Symfony 4 PHPUnit Bridge documentation:
Deprecation notices can be triggered by using:
@trigger_error('Your deprecation message', E_USER_DEPRECATED);Without the @-silencing operator, users would need to opt-out from deprecation notices. Silencing by default swaps this behavior and allows users to opt-in when they are ready to cope with them (by adding a custom error handler like the one provided by this bridge). When not silenced, deprecation notices will appear in the Unsilenced section of the deprecation report.
This boils down to the following example:
set_error_handler(function ($errno, $errstr) {
var_dump($errstr);
}, E_USER_DEPRECATED);
@trigger_error('Will only be seen from a custom error handler', E_USER_DEPRECATED);
Otherwise put, a silenced deprecation notice still can be heard from a custom error handler, if needed, not polluting the usual logs in the same time.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With