Является ли debug_backtrace () безопасным для серьезного использования в рабочей среде? - PullRequest
Новая
       24

Является ли debug_backtrace () безопасным для серьезного использования в рабочей среде?

3 голосов
/ 13 марта 2010

Его функциональность настолько сильна, что я беспокоюсь о его стабильности и производительности.

Что ты думаешь?

UPDATE

Что я делаю, это: 

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

По сути, это просто include ( $included_file );, но внутри этого $included_file он не может найти 3.php, который находится в том же каталоге, в котором находится сам, поэтому я вручную установил cwd, и он работает. Но это будет хорошо, если я найду причину, по которой он не может найти. Что касается необходимости debug_backtrace, это потому, что 3.php включен другим func, так как относительный путь не работает, он должен использовать debug_backtrace чтобы получить включаемый путь к файлу, наконец, используя абсолютный путь, как указано ниже.

Воспроизвести нелегко, так как приведенный выше код находится в контексте метода и многого другого ... Если никто не сталкивался с такой проблемой, я бы хотел остановиться на этом, во всяком случае, стоимость всего лишь 3 дополнительных строки, не так уж и много.

Ответы [ 3 ]

5 голосов
/ 13 марта 2010

debug_backtrace относительно дорогой в моем опыте, поэтому вы должны быть осторожны, он не используется в циклах (например, в пользовательском обработчике ошибок, который перехватывает предупреждения или уведомления и каждый раз выполняет обратную трассировку).

Для любого вида регистрации ошибок, я думаю, что это довольно неоценимо, и потому что это будет вызываться только один раз, определенно не проблема производительности. Конечно, всегда полезно включить обратную трассировку в сообщение об ошибке.

Я не могу понять, почему возникли какие-либо конкретные проблемы со стабильностью этой функции (то есть вызвав ее вызывающей другую аварию), я никогда не слышал о каких-либо проблемах. Единственное «замечание», которое я вижу, это это примечание в комментариях пользователя при использовании объектов в качестве параметров функции, для которых не определен метод _toString.

Конечно, вы никогда не должны выводить результаты обратной трассировки конечному пользователю - это само собой разумеется.

1 голос
/ 13 марта 2010

Что ж, учитывая его название, я не уверен, что использовал бы его как "нормальную" часть своего приложения - хотя я не помню, чтобы читал что-либо, в котором говорилось, что это было либо хорошо, либо плохо.


Я действительно не знаю, что вы имеете в виду под "серьезным использованием", но:

  • Если вам нужна эта функция для работы вашего приложения, это может указывать на проблему в вашем дизайне
  • Эта функция может быть полезна в обработчике ошибок, когда вы хотите регистрировать, как / где произошла ошибка: это сделает файлы журнала более полезными , когда дело доходит до отслеживания источников ошибки

Хотя, не уверен, что «регистрация ошибок» соответствует вашему определению серьезное использование ?

0 голосов
/ 13 марта 2010

Хорошо, насколько я понимаю, проблема в следующем

У вас есть файл php, давайте назовем его «main.php». В "main.php" вы включаете "A.php" из некоторого каталога: 

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

A.php, в свою очередь, включает в себя «B.php», который находится в том же каталоге, что и A.php 

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

проблема: поскольку "/ some / dir /" (где находятся A и B) не является током для "main.php", php не видит B.php из A.php

решение: в A.php используйте полный полный путь к /some/dir. Либо жестко закодируйте его, либо получите динамически через dirname(__FILE__)

# in "A.php"
include dirname(__FILE__) .'/B.php';
...