In #2196, we shortly explored how to best handle errors. We quickly came to the realization that we need more insights. We should explore the possibilities we have a little better and also explore how other projects in the WordPress area do it.

Specifically, we should be able to answer the following question:

• Should we ever use error_log()?
• Under which conditions should we call trigger_error()?
• How does WP_DEBUG affect error handling?
• What’s the best way for developers to hook into Timber to add Timber errors to a custom logging system? Should we use set_error_handler()?
• Which errors should be captured by existing logging systems or services (Query - Monitor, Bugsnag, etc.)?

And when we figured that out, we should document this in the Debugging Guide.

Notes

• When we use error_log(), we log directly to the log. But when we use trigger_error(), it first runs through error handlers set through set_error_handler().
• The set_error_handler() function is what plugins like Query Monitor or Bugsnag use to catch errors and handle them their way. For example, Bugsnag will send you emails with the error, which is very helpful. If we use error_log(), these plugins can’t catch the errors. Errors might be lost in a log that nobody looks at.
• The doing_it_wrong_run and deprecated_function_run actions are mainly used by testing suites to make the special tags like @expectedIncorrectUsage or @expectedDeprecated work.

Any ideas, insights, tips and hints are very welcome.