Title: Back trace?
Last modified: May 2, 2024

---

# Back trace?

 *  Resolved [plaidpowered](https://wordpress.org/support/users/plaidpowered/)
 * (@plaidpowered)
 * [2 years ago](https://wordpress.org/support/topic/back-trace/)
 * I would really love the ability to see a back trace of an error’s origin. Sometimes
   an error is thrown on a WordPress core function because some function up the 
   chain was the culprit, but it’s currently impossible to know where that is. So
   adding the output of **`debug_backtrace`** to the database log, or even if you
   could simply add an action to the `Log_Handler->handle()` function so I could
   add a trace myself, that would be _super helpful._ Thanks for considering it 
   and for providing such a useful plugin!

Viewing 3 replies - 1 through 3 (of 3 total)

 *  Thread Starter [plaidpowered](https://wordpress.org/support/users/plaidpowered/)
 * (@plaidpowered)
 * [2 years ago](https://wordpress.org/support/topic/back-trace/#post-17729062)
 * Closing, because while looking for an alternative solution I discovered the extraordinary
   complexity of such a request and I wonder if it’s even possible. Nevermind!
 *  Plugin Author [Jack Arturo](https://wordpress.org/support/users/verygoodplugins/)
 * (@verygoodplugins)
 * [2 years ago](https://wordpress.org/support/topic/back-trace/#post-17730754)
 * [@plaidpowered](https://wordpress.org/support/users/plaidpowered/) I went down
   that road too 😅
 * In the case of an *actual* fatal error, you will get a backtrace included automatically(
   it’s part of the `message` returned by `error_get_last()`). That’s because FEN
   is triggered directly as a result of the error.
 * But for warnings and other stuff, calling `debug_backtrace()` doesn’t work since
   the error may have happened a long time ago.
 * We looked into registering a custom error hander using `set_error_handler()` 
   instead, but it can conflict with other plugins that are doing the same thing…
   and we couldn’t guarantee 100% reliability.
 * So, that’s the way it is (for now). But if anyone finds a way to reliably get
   a backtrace for all error types I’d love to hear it 🙂
 *  Thread Starter [plaidpowered](https://wordpress.org/support/users/plaidpowered/)
 * (@plaidpowered)
 * [2 years ago](https://wordpress.org/support/topic/back-trace/#post-17730775)
 * There’s long discussions on the PHP set_error_handler documentation comments 
   about this, and at least one super long Stack Overflow thread, PHP simply doesn’t
   seem designed to provide the info we need unless Xdebug is installed. By the 
   time the error gets to the error handler callback, the backtrace has already 
   been lost. Makes it real fun to track down deprecation warnings in production…
 * Thanks for replying, if someday I find a solution (probably won’t until the PHP
   function itself changes) I’ll be sure to let you know.

Viewing 3 replies - 1 through 3 (of 3 total)

The topic ‘Back trace?’ is closed to new replies.

 * ![](https://ps.w.org/fatal-error-notify/assets/icon-256x256.png?rev=3459916)
 * [Fatal Error Notify](https://wordpress.org/plugins/fatal-error-notify/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/fatal-error-notify/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/fatal-error-notify/)
 * [Active Topics](https://wordpress.org/support/plugin/fatal-error-notify/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/fatal-error-notify/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/fatal-error-notify/reviews/)

## Tags

 * [feature request](https://wordpress.org/support/topic-tag/feature-request/)

 * 3 replies
 * 2 participants
 * Last reply from: [plaidpowered](https://wordpress.org/support/users/plaidpowered/)
 * Last activity: [2 years ago](https://wordpress.org/support/topic/back-trace/#post-17730775)
 * Status: resolved