What's the alternative then? If you don't suppress error you were not supposed to receive and cannot fix, then your process will crash when it's not supposed to.
Sorry, but PHP cannot have it both ways and still be described as reliable general-purpose language. It either has to provide stable, consistent behaviour and compliance with standards across all its core extensions OR provide developers with reliable tool to countermeasure.
PHP 7.4 provides reliable tool to countermeasure when core extension is acting out - that makes it a reliable, you can work with it, you can build things without taking personal risks to your career.
So far the only thing certain about PHP 8 is that it removes the tool to countermeasure that was needed in previous versions. What I would expect as a solution would be some kind of reassurance like "we are removing @ shut-op, but we also fixed the reason you needed it in the first place".
IMHO, @ is a terrible operator. Suppressing errors to make them go away is not something I would recommend in any case.
What's the alternative then? If you don't suppress error you were not supposed to receive and cannot fix, then your process will crash when it's not supposed to.
Sorry, but PHP cannot have it both ways and still be described as reliable general-purpose language. It either has to provide stable, consistent behaviour and compliance with standards across all its core extensions OR provide developers with reliable tool to countermeasure.
PHP 7.4 provides reliable tool to countermeasure when core extension is acting out - that makes it a reliable, you can work with it, you can build things without taking personal risks to your career.
So far the only thing certain about PHP 8 is that it removes the tool to countermeasure that was needed in previous versions. What I would expect as a solution would be some kind of reassurance like "we are removing @ shut-op, but we also fixed the reason you needed it in the first place".
See the big picture. This operator creates more problems than it solves.
display_errors
off and logs seems a better choice.