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

[Peter Westwood]

On 1 Jan 2011, at 14:45, Andrew Gray wrote:

> 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.
> 

"The blank white wordpress page is a pretty common problem."

This is a server thing though todo with the fact that displaying errors on a production site is a bad idea - much better handled at a server level where you can catch all errors that cause this rather than some errors.

> 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.  


I don't think this level of granularity is a good idea - all core, plugin and theme code should aim to be notice/warning free with WP_DEBUG enabled.

If you are finding a lot of notices and warning in the plugin / theme code you shouldn't ignore them but feed back to the author about the issues (or even better send a patch) - ignoring these can hide real bugs.

From 3.1 onwards I would recommend you use the debug bar plugin to get your diagnostic information somewhere where you can make use of it.

http://wordpress.org/extend/plugins/debug-bar/

Cheers
-- 
Peter Westwood
http://blog.ftwr.co.uk | http://westi.wordpress.com
C53C F8FC 8796 8508 88D6 C950 54F4 5DCD A834 01C5