¿Es seguro debug_backtrace () para un uso serio en el entorno de producción?

Su funcionalidad es tan fuerte que me preocupa su estabilidad y rendimiento.

¿Qué piensas?

ACTUALIZAR

Lo que estoy haciendo es esto:

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

Esencialmente solo include ( $included_file ); , pero dentro de $included_file 3.php no puede encontrar 3.php que está en el mismo directorio en el que está, así que configuro manualmente el cwd y funciona. Pero sería bueno si encontrara la razón por la que no puede find.Inf Por qué debug_backtrace es necesario, es porque 3.php es incluido por otro func , ya que la ruta relativa no funciona, tiene que usar debug_backtrace para obtener la ruta de acceso del archivo, finalmente usando la ruta absoluta como se menciona a continuación.

No es fácil de reproducir, ya que el código anterior está en el contexto de un método , y mucho más … Si nadie más ha encontrado este tipo de problema, me gustaría simplemente detenerme aquí, de todos modos, el costo es solo el extra de 3 líneas, no es un gran problema.

debug_backtrace es relativamente costoso en mi experiencia, por lo que debe tener cuidado de que no se use en bucles (por ejemplo, en un controlador de error personalizado que atrape advertencias o avisos y realice un rastreo de retroceso cada vez).

Para cualquier tipo de registro de errores, creo que es bastante valioso, y porque se llamará solo una vez, definitivamente no es un problema de rendimiento. Seguramente siempre es bueno incluir una traza inversa en un informe de error.

No veo por qué habría problemas específicos con la estabilidad de esta función (es decir, llamándola causando otra caída), nunca he oído hablar de ningún problema. El único “gotcha” que puedo ver es esta nota en las Notas contribuidas por el usuario cuando se usan objetos como parámetros de función que no _toString definido el método _toString .

Por supuesto, nunca debe enviar los resultados de una búsqueda hacia atrás al usuario final, eso es evidente.

Bueno, teniendo en cuenta su nombre, no estoy seguro de que lo use como parte “normal” de mi solicitud, aunque no recuerdo haber leído nada que dijera que era bueno o malo.

Realmente no sé a qué te refieres con “uso serio”, pero:

  • Si necesita esa función para que su aplicación funcione, puede indicar algún problema en su diseño
  • Esta función puede ser útil en un controlador de errores, cuando desea registrar cómo / dónde ocurrió un error: hará que los archivos de registro sean más útiles , cuando se trata de buscar las fonts de los errores

Sin embargo, ¿no está seguro de que el “registro de errores” corresponde a su definición de uso serio ?

Ok, desde mi entendimiento, el problema es seguir

Tienes un archivo php, llamémoslo “main.php”. En “main.php” está incluyendo “A.php” de algún directorio:

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

A.php, a su vez, incluye ‘B.php’, que está en el mismo directorio que A.php

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

el problema: dado que “/ some / dir /” (donde residen A y B) no es el actual para “main.php”, php no ve B.php de A.php

la solución: en A.php utiliza una ruta completa absoluta a /some/dir . Ya sea hardcode it u dirname(__FILE__) dinámicamente a través de dirname(__FILE__)

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