![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Changes between Initial Version and Version 1 of Ticket #28319, comment 23
- Timestamp:
- 11/23/2014 11:24:19 PM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #28319, comment 23
initial v1 7 7 Right. You also have no exception to intercept either. This is an intentional design though. I understand that. The larger issue with WP_Errors is that there's no way to triage them. It's hard to filter relevant WP_Errors (they exist) from the noise. The WP_Error carries no weight, but it does when handled by the code in core. 8 8 9 This means that not all WP_Errors are equal. I took a stab at trying to figure that out last year (http://carlalexander.ca/diving-into-wordpress-errors/). The main conclusion was that there was no easy way to track them down without checking every hook WordPress. You'd then need data after to see which one relevant or not.9 This means that not all WP_Errors are equal. I took a stab at trying to figure that out last year (http://carlalexander.ca/diving-into-wordpress-errors/). The main conclusion was that there was no easy way to track them down without checking every hook WordPress. You'd then need data after to see which ones are relevant or not. 10 10 11 On top of that, WP_Errors are not always self contained. The most specific example is the http_api_debug hook. The WP_Error sent by the hook is not as useful without other variables passed in the hook. That means that any hook in the WP_Error object (on add or __construct) isn't very useful besides for tracking a message. You lack contextual information.11 On top of that, WP_Errors are not always self contained. The most specific example is the http_api_debug hook. The WP_Error sent by the hook is not as useful without other variables passed in the hook. That means that any hook in the WP_Error object (on add or construct) isn't very useful besides for tracking a message. You lack contextual information. 12 12 13 13 > The REST API will make pretty liberal use of WP_Error (intentionally), and logging all of those alone would be problematic.
