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?
I think the constructor wouldn’t work as the place to log the errors because new WP_Error instances do not always mean there are actual errors. It can just act as a container in case errors are later encountered and added onto the object. For example: https://github.com/WordPress/WordPress/blob/master/wp-includes/ms-functions.php#L430
In that case, the logging would have to be done in the add method.
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?
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