Is debug_backtrace() safe for serious usage in production environment?
Asked Answered
F

3

3

It's functionality is so strong that I worry about its stability and performance.

What do you think?

UPDATE

What I'm doing is this:

    $old_dir = getcwd();
    chdir( dirname($included_file) );
    include ( $included_file );
    chdir( $old_dir );

Essentially it just does include ( $included_file );,but inside that $included_file it can't find 3.php which is in the same directory as itself is in,so I manually set the cwd and it works.But it would be nice if I find the reason why it can't find.As for why debug_backtrace is needed,it's because 3.php is included by another func,since the relative path doesn't work,it has to use debug_backtrace to get the including file path,finally using the absolute path as mentioned below.

It's not easy to reproduce,as the above code is in the context of a method,and much more..If no one else has met this kinda problem I'd like to just stop here,anyway,the cost is just the 3 extra lines,not a big deal.

Freehanded answered 13/3, 2010 at 12:46 Comment(11)
Could you explain a bit further what you're trying to achieve? Why do you want to use this function?Cerise
Take a look at the accepted answer of this post:#2438649Freehanded
But that doesn't explain what it's for and what other (maybe better) alternatives would be. Could be as simple as call(__FILE__);Routinize
No,__FILE__ returns the file where the function is defined,not called.Freehanded
And the primary cause is related with this post:#2438655Freehanded
"No,__FILE__ returns the file where the function is defined" - call(__FILE__); is the function call not the definition. The declaration would be function call($path) ....Routinize
But I need to get the calling file in body part({}) of call(),not by passing parameters.Freehanded
And that was my question: Why? Because if we do not know why we also don't know what viable alternatives there might be. For all I knew passing a parameter could have been perfectly fine. Ok, I've looked at question #2438155. And imho debug_backtrace() would be an ugly, most likely avoidable hack for this scenario.Routinize
@stereofrog,what I want to do is just:get the calling file's abs path,and use chdir() to change to the same directory,to fix the problem that sometimes it won't find even though it's in the same directory,refer to it to understand the whole picture:#2438655Freehanded
@stereofrog,I understand what you mean.But it's a feature,to let the user just provide a filename,indicating it's in the same directory as the including file is inFreehanded
@stereofrog,I've provided more information.I do understand your meaning though.Freehanded
L
6

debug_backtrace is relatively expensive in my experience, so you should be careful it is not used in loops (e.g. in a custom error handler that catches warnings or notices and performs a backtrace every time).

For any kind of error logging, I think it's pretty invaluable, and because it's going to be called only once, definitely not a performance problem. It is surely always good to include a backtrace in an error report.

I can't see why there would be any specific issues with this function's stability (i.e. calling it causing another crash), I've never heard of any problems. The only "gotcha" I can see is this note in the User Contributed Notes when using objects as function parameters that have no _toString method defined.

Of course, you should never output the results of a backtrace to the end user - that goes without saying.

Leucocratic answered 13/3, 2010 at 13:10 Comment(0)
E
1

Well, considering its name, I'm not sure I would use it as a "normal" part of my application -- even though I don't remember having read anything which said that it was either good nor bad.


I don't really know what you mean about "serious usage", but :

  • If you need that function for your application to work, it migh indicate some problem in your design
  • This function can be useful in an error-handler, when you want to log how/where an error happened : it will make the log files more useful, when it comes to tracking down the sources of errors

Though, not sure that "error logging" corresponds to your definition of serious usage ?

Evesham answered 13/3, 2010 at 12:53 Comment(0)
S
0

Ok, from my understanding, the problem is following

You've got a php file, let's call it "main.php". In "main.php" you're including "A.php" from some directory:

# in "main.php"
include '/some/dir/A.php';

A.php, in turn, includes 'B.php', which is in the same directory as A.php

# in "A.php"
include 'B.php'; 

the problem: since "/some/dir/" (where A and B reside) is not the current for "main.php", php does not see B.php from A.php

the solution: in A.php use an absolute full path to /some/dir. Either hardcode it or obtain it dynamically via dirname(__FILE__)

# in "A.php"
include dirname(__FILE__) .'/B.php';
Scour answered 13/3, 2010 at 14:43 Comment(1)
This solution is very obvious and I understood it the first time you mentioned...Freehanded

© 2022 - 2024 — McMap. All rights reserved.