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

[Andrew Gray]

My thoughts on the errors would be.

1.  For production sites: Give a theme the ability to have an error page for errors, other than a blank white page.   Not display the error on screen, but to have something that is more user friendly to both novice developers and end users.  Somewhere you could put a "Fail Whale" like twitter.   Maybe a page that says "An Error has occured".   I like that I can theme the DB error page, why not the parse error page.   The blank white wordpress page is a pretty common problem.

2.  For Development site:  Have an option in wp-Config that shows only parse errors, not all the notices and warnings.   With some of the sites I work on, there are so many notices and warnings, I have to turn off all error to get the site to work.    This is especially true with some of the most common plugins, they have tons of warnings and notices that I am not ever going to fix, but I have to hide.  Then when I get a parse error, I have to update my config to show errors.    

Maybe just making the WP-DEBUG able to be defined as the level of errors you want would work.     If I only want Parse errors, then let me define WP-DEBUG as "E_ERROR | E_PARSE" instead of just True or False.
This would not impact existing configs at all, since you could test for True and keep the old behavior unless it was specified.  

Neither of these ideas would take too much work and I would be happy to do it had a chance to make it into the code.  Otherwise, I will just keep my hack workarounds such as turning on ob_start and using a if statement and a request variable to turn on the debug when I want to see my errors.

Happy New Year to all the WP Hackers List Folks by the way,  I really think this is a great list and everyone is very helpful.  Looking forward to all that the new year has to offer.

Andrew



> n 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?
>