3

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.

sanmai
  • 29,083
  • 12
  • 64
  • 76
  • 2
    I suppose it ensures that errors are logged but not necessarily displayed to the user. That's really the only thing I can think of – Phil Sep 25 '18 at 02:33
  • @Phil Yeah, that's what I came to thinking too. But isn't it better to a have a definite answer? (On that note, normal non-prefixed warnings are also not displayed, only logged. I'm speaking of a stock Debian install.) – sanmai Sep 25 '18 at 02:36
  • You could always just ask the author of one of the commits on GitHub, eg leave a comment on https://github.com/symfony/class-loader/commit/b94aa5c3608cd53444fc4c7a2a506d163eb4a8f3 – Phil Sep 25 '18 at 02:39
  • @Phil funny that you propose to ask a question somewhere else rather than right here, on Stack Overflow – sanmai Sep 25 '18 at 02:50
  • StackOverflow isn't the only place to find answers. If you want to know why a developer did something, ask them. You could then use their answer here to answer your own question – Phil Sep 25 '18 at 02:52
  • As a developer myself I can tell that my question there is easy to overlook, and for the amount of communications Symfony folks receive, twice as easy. It is much better to ask such questions here on SO. That's what it for! – sanmai Sep 25 '18 at 02:53
  • 1
    (No harm in asking in both places. I would never have come across the question if posted there.) – Progrock Sep 25 '18 at 03:14
  • 1
    I'm voting to close this question as off-topic because the question has no real problem. This means the question is off topic here on SO. And I assume any answer to the question is opinion based. – Andreas Sep 25 '18 at 03:22
  • @Andreas well I'm sure there's a valid fact based reason people do that. Am I correct that you think there's no reason at all? – sanmai Sep 25 '18 at 03:28
  • @Progrock I've pinged a Symfony's Slack channel, let's see if anything comes from that. – sanmai Sep 25 '18 at 03:29
  • If it's for the reason I mentioned in the first comment, I think [`error_log()`](http://php.net/manual/function.error-log.php) is a much better fit. Me saying _"I think"_ does highlight how this is really a personal preference, thus it is probably opinion based – Phil Sep 25 '18 at 03:30
  • That is not what I meant, I just say this question does not have a problem. A problem is the key to if a question is on topic or off topic at SO. Even if we say it's on topic, I still believe any answer to the question is opinion based. I don't use this error thing, and that is probably because my opinion is that I don't need it. Or that I have solved the same "problem" with something else. So that means it's opinion based. I don't see much difference between this question and questions about "what does this injected code do?" – Andreas Sep 25 '18 at 07:16
  • @Andreas I disagree. My questions is whenever I should follow the same approach, it has nothing to do with "what does this injected code do?" type of questions. – sanmai Sep 25 '18 at 07:52
  • 1
    Perhaps some IDEs or quality check tools pick up on `trigger_error(..., E_USER_DEPRECATED)` statements to highlight such problems…? I know Python IDEs certainly do with equivalent code. – deceze Sep 25 '18 at 07:58
  • @sanmai you didn't read my full comment. Read it again. There is more than "injected" – Andreas Sep 25 '18 at 08:04
  • @Andreas well, maybe, but it doesn't matter now since there's an answer I needed – sanmai Sep 25 '18 at 08:36

1 Answers1

3

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.

sanmai
  • 29,083
  • 12
  • 64
  • 76