`trigger_error` vs` throw Exception` en el contexto de los métodos mágicos de PHP

Estoy teniendo un debate con un colega sobre el uso correcto (si lo hay) trigger_erroren el contexto de los métodos mágicos . En primer lugar, creo que trigger_errordebería evitarse a excepción de este caso.

Digamos que tenemos una clase con un método foo()

class A {
    public function foo() {
        echo 'bar';
    }
}

Ahora digamos que queremos proporcionar exactamente la misma interfaz pero usar un método mágico para capturar todas las llamadas a métodos

class B {
    public function __call($method, $args) {
        switch (strtolower($method)) {
        case 'foo':
            echo 'bar';
            break;
        }
    }
}

$a = new A;
$b = new B;

$a->foo(); //bar
$b->foo(); //bar

Ambas clases son iguales en la forma en que responden, foo()pero difieren cuando se llama a un método no válido.

$a->doesntexist(); //Error
$b->doesntexist(); //Does nothing

Mi argumento es que los métodos mágicos deberían llamar trigger_errorcuando se detecta un método desconocido

class B {
    public function __call($method, $args) {
        switch (strtolower($method)) {
        case 'foo':
            echo 'bar';
            break;
        default:
            $class = get_class($this);
            $trace = debug_backtrace();
            $file = $trace[0]['file'];
            $line = $trace[0]['line'];
            trigger_error("Call to undefined method $class::$method() in $file on line $line", E_USER_ERROR);
            break;
        }
    }
}

Para que ambas clases se comporten (casi) de manera idéntica

$a->badMethod(); //Call to undefined method A::badMethod() in [..] on line 28
$b->badMethod(); //Call to undefined method B::badMethod() in [..] on line 32

Mi caso de uso es una implementación de ActiveRecord. Utilizo __callpara capturar y manejar métodos que esencialmente hacen lo mismo pero que tienen modificadores como Distincto Ignore, por ejemplo

selectDistinct()
selectDistinctColumn($column, ..)
selectAll()
selectOne()
select()

o

insert()
replace()
insertIgnore()
replaceIgnore()

Métodos como where(), from(), groupBy(), etc. están codificadas.

Mi argumento se resalta cuando accidentalmente llamas insret(). Si mi implementación de registro activa codificara todos los métodos, sería un error.

Como con cualquier buena abstracción, el usuario debe desconocer los detalles de implementación y confiar únicamente en la interfaz. ¿Por qué la implementación que usa métodos mágicos debería comportarse de manera diferente? Ambos deberían ser un error.

Tomar dos implementaciones de la misma interfaz ActiveRecord ( select(), where(), etc.)

class ActiveRecord1 {
    //Hardcodes all methods
}

class ActiveRecord2 {
    //Uses __call to handle some methods, hardcodes the rest
}

Si llama a un método no válido en la primera clase, por ejemplo ActiveRecord1::insret(), el comportamiento predeterminado de PHP es desencadenar un error . Una llamada de función / método no válida no es una condición que una aplicación razonable quiera capturar y manejar. Claro, puede detectarlo en lenguajes como Ruby o Python donde un error es una excepción, pero otros (JavaScript / algún lenguaje estático / más) fallarán.

Volver a PHP: si ambas clases implementan la misma interfaz, ¿por qué no deberían exhibir el mismo comportamiento?

Si __callo __callStaticdetectar un método válido, que debe dar lugar a un error de imitar el comportamiento por defecto de la lengua

$class = get_class($this);
$trace = debug_backtrace();
$file = $trace[0]['file'];
$line = $trace[0]['line'];
trigger_error("Call to undefined method $class::$method() in $file on line $line", E_USER_ERROR);

No estoy discutiendo si los errores deberían usarse sobre las excepciones (no deberían hacerlo al 100%), sin embargo, creo que los métodos mágicos de PHP son una excepción (juego de palabras :)) a esta regla en el contexto del lenguaje

Voy a lanzar mi opinión obvia, pero si la usas en trigger_errorcualquier lugar, entonces estás haciendo algo mal. Las excepciones son el camino a seguir.

Ventajas de las excepciones:

• Pueden ser atrapados. Esta es una gran ventaja, y debería ser la única que necesita. Las personas pueden probar algo diferente si esperan que exista la posibilidad de que algo salga mal. Los errores no te dan esta oportunidad. Incluso configurar un controlador de errores personalizado no tiene una vela para simplemente detectar una excepción. Con respecto a sus comentarios en su pregunta, lo que es una aplicación 'razonable' depende completamente del contexto de la aplicación. Las personas no pueden atrapar excepciones si piensan que nunca sucederá en su caso. No darles a las personas una opción es algo malo.
• Apilar rastros. Si algo sale mal, usted sabe dónde y en qué contexto ocurrió el problema. ¿Alguna vez ha tratado de rastrear dónde proviene un error de algunos de los métodos principales? Si llama a una función con muy pocos parámetros, obtiene un error inútil que resalta el inicio del método al que llama y deja totalmente de lado desde dónde está llamando.
• Claridad. Combine los dos anteriores y obtendrá un código más claro. Si intenta utilizar un controlador de errores personalizado para manejar los errores (por ejemplo, para generar seguimientos de pila para errores), todo su manejo de errores se realiza en una función, no donde se generan realmente los errores.

Abordar sus inquietudes, llamar a un método que no existe puede ser una posibilidad válida . Esto depende completamente del contexto del código que está escribiendo, pero hay algunos casos en los que esto puede suceder. Al abordar su caso de uso exacto, algunos servidores de bases de datos pueden permitir alguna funcionalidad que otros no. Usar try/ catchy excepciones en __call()vs. una función para verificar capacidades es un argumento completamente diferente.

El único caso de uso que se me ocurre para usar trigger_errores para E_USER_WARNINGo más bajo. Disparar un pensamiento E_USER_ERRORes siempre un error en mi opinión.

Los errores estándar de PHP deben considerarse obsoletos. PHP proporciona una clase incorporada ErrorException para convertir errores, advertencias y avisos en excepciones con un seguimiento de pila completo y adecuado. Lo usas así:

function errorToExceptionHandler($errNo, $errStr, $errFile, $errLine, $errContext)
{
if (error_reporting() == 0) return;
throw new ErrorException($errStr, 0, $errNo, $errFile, $errLine);
}
set_error_handler('errorToExceptionHandler');

Usando eso, esta pregunta se vuelve discutible. Los errores incorporados ahora generan excepciones, por lo que su propio código también debería hacerlo.

OMI, este es un caso de uso perfectamente válido para trigger_error:

function handleError($errno, $errstring, $errfile, $errline, $errcontext) {
    if (error_reporting() & $errno) {
        // only process when included in error_reporting
        return handleException(new \Exception($errstring, $errno));
    }
    return true;
}

function handleException($exception){
    // Here, you do whatever you want with the generated
    // exceptions. You can store them in a file or database,
    // output them in a debug section of your page or do
    // pretty much anything else with it, as if it's a
    // normal variable

    switch ($code) {
        case E_ERROR:
        case E_CORE_ERROR:
        case E_USER_ERROR:
            // Make sure script exits here
            exit(1);
        default:
            // Let script continue
            return true;
    }
}

// Set error handler to your custom handler
set_error_handler('handleError');
// Set exception handler to your custom handler
set_exception_handler('handleException');


// ---------------------------------- //

// Generate warning
trigger_error('This went wrong, but we can continue', E_USER_WARNING);

// Generate fatal error :
trigger_error('This went horrible wrong', E_USER_ERROR);

Usando esta estrategia, obtienes el $errcontextparámetro si lo haces $exception->getTrace()dentro de la función handleException. Esto es muy útil para ciertos propósitos de depuración.

Desafortunadamente, esto funciona solo si lo usa trigger_errordirectamente desde su contexto, lo que significa que no puede usar una función / método de envoltura para crear un alias de la trigger_errorfunción (por lo que no puede hacer algo como function debug($code, $message) { return trigger_error($message, $code); }si desea los datos de contexto en su seguimiento).

He estado buscando una mejor alternativa, pero hasta ahora no he encontrado ninguna.