Hiding deprecation warnings from a vendor-provided class only

Question

We have an app that includes a very very old class to connect to a proprietary database's API. This code is generating a large number of deprecation errors that then get logged, polluting our log files.

We'd like to essentially ignore the deprecation errors only for this vendor-provided class, but I am having trouble finding the best way to do this. Options that I've seen:

Supressing the warnings using @. It looks like this does not work for includes, only for functions that return a value.

Creating a wrapper script that contains the include, and turn off the warnings prior to the include statement. As ini_set acts globally, turning off all deprecation warnings, this is not a viable solution.

Updating the vendor-provided script. We'd rather not go down this path, given the extra work and maintenance should a new version arrive that does not fully address these errors, but adds new functionality, for example.

Any other options to disable warnings in this one particular vendor library that I am missing?

Have you tried putting the include inside a function, then calling the function with the @ operator? — Eugen Rieck, Nov 08 '13 at 23:23
If they provide an updated script that doesn't include fixing it, then it wouldn't be worth updating to it in the first place. Honestly I'd either go for the "fix the errors yourself" route or else the "find a new script" route. Making your errors go away by sticking your head in the sand is almost always a bad idea — CrayonViolent, Nov 08 '13 at 23:25
You could `ini_set` to suppress errors at the top of the vendor script, and `ini_set` back to normal at the bottom... unless the vendor provided file contains classes or functions that are called individually from other places? — Patrick Moore, Nov 08 '13 at 23:36
@SetSailMedia: According to the question it's a database API class, so almost certainly the deprecation errors appear only after your start calling methods. — Jon, Nov 08 '13 at 23:41
@EugenRieck we haven't but will look into a solution like this (Jon's answer, which is similar to yours) — Unpossible, Nov 13 '13 at 21:03

Jon · Accepted Answer · 2013-11-08T23:44:29.600

You can attach a user error handler to eat the error up before PHP sees it. This handler would only intervene if the error was generated inside the source of the guilty library. For example:

class SingleSourceFileErrorSuppressor
{
    private $_file;

    public function __construct($file)
    {
        $this->_file = $file;
    }

    public function handleError($errno, $message, $file)
    {
        if ($file !== $this->file) return false;
    }
}

You would use the class like this:

$naughtyLibrary = realpath('naughty.class.php');
$suppressor = new SingleSourceFileErrorSuppressor($naughtyLibrary);
set_error_handler([$suppressor, 'handleError'], E_DEPRECATED);
require($naughtyLibrary);

Updated: I decided that modifying the vendor's library source is not the best idea even for trivial modifications because you have to remember to maintain them, so changed the suggested installation procedure. The new procedure has a different drawback: it doesn't automatically search the include_path. The original suggestion is available through the answer's edit history. Choose your poison.

Hiding deprecation warnings from a vendor-provided class only

1 Answers1

Linked