Error Handler Broken

[dotsam]

It looks like master is already on 2.0 now, which doesn't have this issue, but wanted to raise it in case there is to be a maintenance release of the 1.x series, and to let others know about it.

#58 was to add functionality to ignore certain classes of error, adding the following code:

acorn/src/Acorn/Bootstrap/HandleExceptions.php

Lines 186 to 197 in fa60ba1

	/**
	* Determine if the exception is in the ignore list.
	*
	* @param \Throwable $e
	* @return bool
	*/
	protected function shouldntIgnore(Throwable $e)
	{
	return ! is_null(Arr::first($this->ignoredErrors, function ($type) use ($e) {
	return $e instanceof $type;
	}));
	}

But from what I can see, this code doesn't work. It's checking if ErrorException is an instance of 'E_USER_DEPRECATED', which I don't believe will ever work. Something like:

$e->getSeverity() === constant($type)

is what I can come up with to get this to work as designed.

My workaround in a Sage 10 theme with Acorn v1.1.0 is to check if the Acorn error handler is the one registered, and if so, replace it with one that unconditionally throws an ErrorException

add_action('after_setup_theme', function () {
    $previous_handler = set_error_handler(null);

    // Check if the Acorn error handler was actually the one we just removed or not
    if (!empty($previous_handler[0]) && $previous_handler[0] instanceof \Roots\Acorn\Bootstrap\HandleExceptions) {
        set_error_handler(function ($level, $message, $file = '', $line = 0, $context = []) {
            throw new ErrorException($message, 0, $level, $file, $line);
        });
    } else {
        set_error_handler($previous_handler);
    }
}, 6);

[strarsis]

@dotsam: Thanks a lot for your workaround.
I just added the first line for now in order to get around the handler as it breaks the page by injecting "rich" error message HTML.

add_action('after_setup_theme', function () {
    $previous_handler = set_error_handler(null);
});

The rest of your workaround code still seems to have issues handling error_reporting levels.
Could be the bitwise comparison the reason, see this related issue: #100

[joshuafredrickson]

@strarsis Thank you!

I was receiving white screens in production (with no errors or logs) with every change in post status: publish, trash, etc. No issues in staging or development. In my case, I tracked it down specifically to WP_DEBUG being either undefined or false.

Adding this snippet fixed the issue in production:

add_action('after_setup_theme', function () {
    if (! defined('WP_DEBUG') || WP_DEBUG === false) {
        $previous_handler = set_error_handler(null);
    }
});