Reputation: 409
I am using some external libraries which uses the @
error silencing operator.
The library is generating some errors and it becomes difficult to point the exact location where the error occurs as the @
operator hides it.
Is there any way to easily disable the @-operator in the code without making any actual changes to the code?
I have tried Scream Pecl extension but it does not seem to work. It's available for PHP 5.6 version while I am using PHP 7.
Scream extension is installed and is enabled in php.ini by using scream.enabled=1
(as per their documentation) but the error still doesn't show or log.
Upvotes: 3
Views: 164
Reputation: 47369
You cannot disable the behaviour of the @
symbol, but you can log/handle these errors nonetheless by using your own error handler.
From the docs:
If you have set a custom error handler function with
set_error_handler()
then it will still get called,
What this operator does is basically set error_reporting
to 0
for one statement. Which is also reflected on the same docs:
but this custom error handler can (and should) call
error_reporting()
which will return 0 when the call that triggered the error was preceded by an@
.
So, assuming you could have something like this very simple implementation, you would need to fine tune the details:
function exceptional_error_handler($severity, $message, $file, $line)
{
if (error_reporting() === 0) {
// assuming your application always runs with `error_handling !== 0`,
// e.g. by setting this during application bootstrap
// that we got here means this is was a "silenced" error
throw new \ErrorException("Silenced error! '$message'", 0, $severity, $file, $line);
}
// regular (non-silenced) errors should respect your error_reporting levels
if (!(error_reporting() & $severity)) {
// This error code is not included in error_reporting
return;
}
// everything else is converted to an exception
throw new \ErrorException($message, 0, $severity, $file, $line);
}
set_error_handler("exceptional_error_handler");
This converts all errors to exceptions, simply noting with a different message when it was a "silenced" error, but your error handler could do logging or have any kind of custom logic.
By doing this, you could leave the existing/third party code untouched, and just add the error handling logic to the bootstrapping part of your application.
Upvotes: 1