stacktrace - PHP debug_backtrace en el código de producción para obtener información sobre el método de llamada?

throw error php

Question

¿Existe alguna razón convincente para no usar debug_backtrace con el único propósito de determinar la clase, el nombre y la lista de parámetros del método de llamada? No para fines de depuración. Tiene la palabra "debug" en el nombre de la función, lo que me hace sentir un poco sucio de usarlo de esta manera, pero se ajusta a la factura de lo que necesitaba hacer (una sola función que se puede llamar desde muchos lugares y necesita llamar al método de llamada de otro sistema). Funciona, pero ¿sigue siendo una mala idea? Si es así, ¿por qué?

Answer 1

¿Existe alguna razón convincente para no usar debug_backtrace con el único propósito de determinar la clase, el nombre y la lista de parámetros del método de llamada?

Sí. El punto es que, en general, es un signo de mal diseño si su código requiere un acoplamiento tan ajustado que el destinatario debe tener esta información sobre quien llama. Por lo tanto, si siente la necesidad de utilizar esta información, probablemente deba reconsiderar su diseño.

Dicho sin rodeos, el destinatario no debería necesitar tener esta información para realizar su tarea. Las excepciones, por supuesto, giran en torno a la depuración, el registro y, en general, otros tipos de introspección de código (pero incluso allí, ten cuidado).

Answer 2

debug_backtrace es una de las funciones de manejo de errores de PHP. El manual alienta a los usuarios a definir sus propias reglas de manejo de errores, así como a modificar la forma en que se pueden registrar los errores. Esto le permite cambiar y mejorar los informes de errores para satisfacer sus necesidades. Esto también implica que el rendimiento alcanzado por el uso de estas funciones es insignificante.

Creo que lo que estás haciendo está bien.

Answer 3

Dijiste en un comentario

La tarea del destinatario es llamar al mismo método que lo llamó en una computadora diferente. Es para evitar tener una función API diferente para cada fuente posible, lo que reduce considerablemente la cantidad de código en el sistema. ¿Sigue siendo malo?

Entonces quieres hacer lo siguiente:

• Llamadas de la función foo ()
• Función reflective () , que realiza un seguimiento de depuración y solicitudes
• http://example.com/REST/ foo

Suponiendo, por supuesto, que use las solicitudes HTTP para disparar la llamada remota.

Esta es una configuración un poco extraña. Si está creando el sistema desde cero, le sugiero que trate de evitarlo. Si lo calzas con un sistema heredado, entonces supongo que lo entiendo.

Sugeriría que siempre seas más explícito cuando puedas. El uso de la introspección de la pila mágica puede ahorrarle un poco de codificación, pero para otro desarrollador su código será completamente desconcertante. Si está sugiriendo que pase la clase y el nombre de la función a la función que previamente estaba haciendo la reflexión. Entonces no hay ambigüedad sobre lo que está sucediendo.

• Llamadas de la función foo ()
• Función reflexiva (__ CLASS__, __FUNCTION__) , que solicita
• http://example.com/REST/ foo

Answer 4

Se siente un poco sucio, pero como ha sido bien documentado, opinado y golpeado hasta la muerte en otro lado, PHP no es un sistema diseñado para la elegancia.

Una razón muy intrincada para no usar debug_backtrace para la lógica de la aplicación es que algún futuro desarrollador que trabaje en PHP podría decidir "es solo una función de depuración, el rendimiento no importa".

Si le interesa una forma "mejor" de hacer esto, probablemente podría usar las constantes mágicas de PHP para pasar el método de llamada y el nombre de clase, y luego usar un objeto ReflectionMethod para extraer cualquier otra información que necesite.

Pongo mejores comillas porque, aunque esto sería más limpio y más correcto, la sobrecarga de crear instancias de un objeto Reflection puede ser mayor que usar la función debug_backtrace.

Answer 5

Estoy pensando en usar debug_backtrace para depurar las declaraciones de mysql. Es mucho más fácil identificar las consultas erróneas o lentas cuando tienes un encabezado como este al comienzo de cada consulta dentro de los registros de la base de datos:

/*Called from /var/www/micimacko.php at line 28*/ SELECT count(*) FROM rofibeka;

La pregunta permanece ¿Qué hay de rendimiento / fiabilidad.

Answer 6

La respuesta correcta es que está totalmente bien . Alan señala la falta de elegancia de PHP, por lo que no voy a reiterar sus puntos. La razón para (no tener miedo a) usar debug_backtrace en el código de tiempo de ejecución es porque PHP es principalmente un lenguaje libre de contexto. Cada función no sabe ni puede conocer la "intención" del que llama sin utilizar los nombres de las funciones mágicas (por ejemplo, en una clase, por ejemplo, __toString ()) con el casting. Consideremos el caso en el que tiene una clase, en la que (en un método), desea proporcionar acceso a las propiedades de la clase llamante (externa). Es realmente desordenado y propenso a pasar errores ($ this) a través de la función API. (Especialmente cuando quieres array_map o call_user_func_array)

p.ej

<?
class a {
public $v = ''xyz'';
function __construct($x,$y)
{
$b = new b();
}
}
class b {
function __construct()
{
$start = microtime();
$x = debug_backtrace();
$end = microtime();
echo ($end-$start) . "/n";
print_r($x);
$obj = $x[1][''object''];
print_r($obj);
}
}
$a = new a(1,2);
?>

El debug_backtrace le dará acceso al contexto de la clase a en la __construcción de b. Ahora puede pasar algunas variables de estado de la clase actual sin pasar $ this alrededor o tratando de adivinarlo de los nombres de clase o bloquearlo poniéndolo en globales.

Para aquellos que están interesados ​​en el tiempo, la microtime fue 2.7E-5. Suficientemente rapido. Simplemente no lo pongas por un tiempo (1).