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?
3 Comments
I think the constructor wouldn’t work as the place to log the errors because new
WP_Errorinstances do not always mean there are actual errors. It can just act as a container in case errors are later encountered andadded onto the object. For example: https://github.com/WordPress/WordPress/blob/master/wp-includes/ms-functions.php#L430In that case, the logging would have to be done in the
addmethod.Yeah, that’s my fear. In the case of using the
addmethod, 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_logwhen an error should be logged. I suppose the problem with logging fromWP_Erroris 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 ifWP_Errorinstances did log errors, then they should be opt-in via someWP_DEBUG_LEVEL.An alternative to putting the error logging in the
__constructoraddmethods would be to put it in the__destructmethod, that way it would be assured to have had already accumulated all errors that would ever be added to the instance.