Differences

This shows you the differences between two versions of the page.

--- rfc:debug_backtrace_depth [2021/03/13 17:25] – tandre
+++ rfc:debug_backtrace_depth [2021/04/09 04:06] – tandre
@@ Line 107: / Line 107: @@
 ===== Future Scope =====
 The behavior of ''debug_backtrace'' and ''debug_print_backtrace'' could be changed to make $limit be consistent with the documentation in a separate RFC. https://www.php.net/manual/en/function.debug-backtrace.php#refsect1-function.debug-backtrace-parameters.
+===== Proposed PHP Version =====
+.1
+===== Discussion =====
+==== Limited to a specific use case ====
+https://externals.io/message/113502#113821
+<blockquote>
+There hasn't been much discussion on this one, probably because the
+functionality and use cases are so specific. I'm not really convinced by
+your examples.
+For the purpose of printing debug logs, using an engine-provided depth is
+non-ideal, because any intermediate helper functions will count towards the
+depth. Tracking your own depth will result in a more meaningful/predictable
+output.
+For tracking down infinite recursion, isn't this what the xdebug recursion
+limit is for? You'll directly get your recursive stack trace, which should
+make it obvious where the infinite recursion occurs. Using
+debug_backtrace_depth() for this purpose means that you actually already
+need to know where you are infinitely recursing in order to place the guard.
+If you want to find places where your code would hit the xdebug recursion
+limit, then why not run it under xdebug and find out, rather than trying to
+simulate the same behavior manually? That again requires that you actually
+place relevant guards in the first place, which makes this another chicken
+and egg problem.
+</blockquote>
 ===== Proposed Voting Choices =====
 Yes/No, requiring a 2/3 majority

Differences

Page Tools