[wp-hackers] Better Error Handling for both Development and Production Servers

[Andrew Nacin]

On Fri, Dec 31, 2010 at 3:37 PM, Andrew Gray <andrew at graymerica.com> wrote:

> Does anyone think that a patch for an improved error handler in
> wp-includes/load.php would be well received or implemented into the core.
>
> I would love a setting to only show Fatal / parse errors when developing.
>  Something that only show these errors and ignores all the deprecated,
> notices and other errors that come from plugins and from the core wordpress
> when I was developing.  Or at lease improve the options available for
> WP-config from DEBUG only.
>

Parse errors can't be suppressed during runtime. Why would you want to
suppress E_WARNING though? The only use case really for suppressing E_NOTICE
is if *other* plugins are spitting out a ton of notices. But if you're
developing on just core and your plugin, then you should really want to
prevent all E_NOTICE issues. (If you ever find one in core, *please* report
it.)

Thus, this really just comes down to WP_DEBUG versus not. If WP_DEBUG is on,
you get all notices. If it's off, you don't get any notices. What's the
third option you're looking for?

Also, an error handler for production websites that is something other than
> a blank page.    Something with a little data or that could be customized
> with a theme.  I was thinking of using
> http://php.net/manual/en/function.set-error-handler.php  and a shutdown
> function (when possible) to improve the user experience.
>

display_errors should never be enabled on a production site. You should log
these instead, via the php.ini error_log setting. If you really want to use
an error handler or shutdown function, you can do that yourself for sure.


> Of course all of this would be optional, and not included in the code
> unless people turn it on.
>
> Also if you enable define('E_DEPRECATED', false) ; I get a Fatal error:
> Unsupported operand types in ****/wp-includes/load.php on line 260
>

You shouldn't define E_DEPRECATED. It's a core PHP constant. We're only
doing that to detect whether you're on PHP 5.3 or not. I just committed this
comment to trunk: http://core.trac.wordpress.org/changeset/17194, so I hope
that helps.

Does anyone think that if I worked up a patch for all this, it would be
> accepted.
>

Improvements here would certainly be considered. Could you read through my
feedback and re-propose what you'd like to see?

Thanks!
Nacin