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

Question

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

Как вы думаете?

ОБНОВИТЬ

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

    $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 дополнительных линии, не имеет большого значения.

Answer 1

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

У вас есть файл 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';