PHP debug_backtrace in production code to get information about calling method?
Is there a compelling reason to not use debug_backtrace for the sole purpose of determining the calling method's class, name, and parameter list? Not for debugging purposes. It has the word "debug" in the function name, which makes me feel a little dirty to be using it in this way, but it fit the bill for what I needed to do (a single function that can be called from many places and needs to call the calling method from another system). It works, but is this still a bad idea? If so, why?
It does feel a little dirty, but as has been well documented, opined, and beaten to death elsewhere, PHP isn't a system designed for elegance.
One highly convoluted reason not to use debug_backtrace for application logic is it's possible some future developer working on PHP could decide "it's just a debug function, performance doesn't matter".
If you're interested in a "better" way of doing this, you could probably use PHP's magic constants to pass in the calling method and class name, and then use a ReflectionMethod object to extract any other information you need.
I put better in quotes because, while this would be cleaner and more correct, the overhead of instantiating a Reflection object may be greater than using the debug_backtrace function.
Is there a compelling reason to not use debug_backtrace for the sole purpose of determining the calling method's class, name, and parameter list?
Yes. The point is, it's generally a sign of bad design if your code requires such a tight coupling that the callee has to have these information about its caller. Therefore, if you feel the need to use these information, you probably should rethink your design.
Put bluntly, the callee should not need to have these information to perform its task. The exceptions, of course, revolve around debugging, logging and more generally other kinds of code introspection (but even there, beware of it).
debug_backtrace is one of the PHP error handling functions. The manual encourages users to define their own error handling rules, as well as modify the way the errors can be logged. This allows you to change and enhance error reporting to suit your needs. This also implies that the performance hit from using these functions is negligible.
I think what you're doing is just fine.
You said in a comment
The callee's task is to call the same method that called it on a different computer. It's to avoid having a different API function for every possible source, which reduced the amount of code in the system considerably. Is it still bad
So you want to do the following:
- Function foo() calls
- Function reflective(), which does a debug backtrace and requests
- http://example.com/REST/foo
Assuming, of course, that you use HTTP requests to fire off the remote call.
This is a bit of a strange set up. If you are creating the system from scratch then I'd suggest trying to work around it. If you're shoehorning it into a legacy system then I suppose I understand.
I'd suggest that you always be more explicit when you can. Your use of magic stack introspection might save you a little bit of coding, but to another developer your code will be completely baffling. If'dsuggest that you pass the class and function name to the function that was previously doing the reflection. Then there is no ambiguity about what is happening.
- Function foo() calls
- Function reflective(__CLASS__, __FUNCTION__), which requests
- http://example.com/REST/foo