Status

An idea: Use creation of WP_Error objects as a way of tracking application exceptions. If WP_Error had an action in the __construct() method, you could easily error_log() WP_Error codes and messages.

Can someone tell me why this is a bad idea (other than exploding your error log), or whether there’s a better approach?

Author: Daniel Bachhuber

Proud father x2. Principal, Hand Built. Maintainer, WP-CLI.

3 thoughts on “Status”

    1. Yeah, that’s my fear. In the case of using the add method, we’d need to update the constructor to use that.

      Do you have an alternate approach for exception logging at the moment?

      1. Not really. I explicitly call error_log when an error should be logged. I suppose the problem with logging from WP_Error is that many of the instances would relate to user errors (e.g. not filling out a form fully) and not logic errors in the code (e.g. term doesn’t exist), and so the error log would get filled up with noise from non-code issues. So if WP_Error instances did log errors, then they should be opt-in via some WP_DEBUG_LEVEL.

        An alternative to putting the error logging in the __construct or add methods would be to put it in the __destruct method, that way it would be assured to have had already accumulated all errors that would ever be added to the instance.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s