`trigger_error` vs` buttare l'eccezione` nel contesto dei metodi magici di PHP

Sto discutendo con un collega sull'uso corretto (se presente) di trigger_errornel contesto dei metodi magici . In primo luogo, penso che trigger_errordovrebbe essere evitato, tranne per questo caso.

Supponiamo che abbiamo una classe con un metodo foo()

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

Ora diciamo che vogliamo fornire la stessa identica interfaccia ma usare un metodo magico per catturare tutte le chiamate di metodo

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

Entrambe le classi sono uguali nel modo in cui rispondono foo()ma differiscono quando si chiama un metodo non valido.

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

La mia tesi è che i metodi magici dovrebbero chiamare trigger_errorquando viene catturato un metodo sconosciuto

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;
        }
    }
}

In modo che entrambe le classi si comportino (quasi) in modo identico

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

Il mio caso d'uso è un'implementazione di ActiveRecord. Uso __callper catturare e gestire metodi che essenzialmente fanno la stessa cosa ma hanno modificatori come Distincto Ignore, ad esempio

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

o

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

Metodi come where(), from(), groupBy(), ecc, sono hard-coded.

Il mio argomento viene evidenziato quando si chiama accidentalmente insret(). Se l'implementazione del mio record attivo codificasse tutti i metodi, sarebbe un errore.

Come per ogni buona astrazione, l'utente dovrebbe essere ignaro dei dettagli di implementazione e fare affidamento esclusivamente sull'interfaccia. Perché l'implementazione che utilizza metodi magici dovrebbe comportarsi diversamente? Entrambi dovrebbero essere un errore.

Prendere due implementazioni della stessa interfaccia ActiveRecord ( select(), where(), ecc)

class ActiveRecord1 {
    //Hardcodes all methods
}

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

Se chiami un metodo non valido sulla prima classe, ad esempio ActiveRecord1::insret(), il comportamento PHP predefinito è quello di innescare un errore . Una chiamata di funzione / metodo non valida non è una condizione che un'applicazione ragionevole vorrebbe catturare e gestire. Certo, puoi prenderlo in lingue come Ruby o Python dove un errore è un'eccezione, ma altri (JavaScript / qualsiasi linguaggio statico / altro?) Falliranno.

Torna a PHP - se entrambe le classi implementano la stessa interfaccia, perché non dovrebbero mostrare lo stesso comportamento?

Se __callo __callStaticrileva un metodo non valido, dovrebbero attivare un errore per imitare il comportamento predefinito della lingua

$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);

Non sto discutendo se gli errori debbano essere utilizzati rispetto alle eccezioni (al 100% non dovrebbero), tuttavia credo che i metodi magici di PHP siano un'eccezione - gioco di parole :) - per questa regola nel contesto del linguaggio

Sto per lanciare la mia opinione supponente là fuori, ma se usi trigger_errorovunque, allora stai facendo qualcosa di sbagliato. Le eccezioni sono la strada da percorrere.

Vantaggi delle eccezioni:

• Possono essere catturati. Questo è un enorme vantaggio e dovrebbe essere l'unico di cui hai bisogno. Le persone possono effettivamente provare qualcosa di diverso se si aspettano che ci sia una possibilità che qualcosa vada storto. L'errore non ti dà questa opportunità. Anche l'impostazione di un gestore errori personalizzato non regge il confronto con una semplice eccezione. Per quanto riguarda i tuoi commenti nella tua domanda, quale sia un'applicazione "ragionevole" dipende interamente dal contesto dell'applicazione. Le persone non possono cogliere eccezioni se pensano che non accadrà mai nel loro caso. Non dare alle persone una scelta è una cosa cattiva ™.
• Pila di tracce. Se qualcosa va storto, sai dove e in quale contesto si è verificato il problema. Hai mai provato a rintracciare la provenienza di un errore da alcuni dei metodi principali? Se si chiama una funzione con troppi parametri si ottiene un errore inutile che evidenzia l'inizio del metodo che si sta chiamando e lascia completamente da dove sta chiamando.
• Chiarezza. Combina i due precedenti e otterrai un codice più chiaro. Se si tenta di utilizzare un gestore errori personalizzato per gestire gli errori (ad es. Per generare tracce di stack per errori), tutta la gestione degli errori è in una funzione, non dove gli errori vengono effettivamente generati.

Affrontare le tue preoccupazioni, chiamare un metodo che non esiste può essere una possibilità valida . Questo dipende interamente dal contesto del codice che stai scrivendo, ma ci sono alcuni casi in cui ciò può accadere. Affrontando l'esatto caso d'uso, alcuni server di database potrebbero consentire alcune funzionalità che altri non lo fanno. L'uso di try/ catche le eccezioni __call()rispetto a una funzione per verificare le capacità è un argomento completamente diverso.

L'unico caso d'uso che mi viene in mente per l'utilizzo trigger_errorè per E_USER_WARNINGo inferiore. A E_USER_ERRORmio avviso, innescare un pensiero è sempre un errore.

Gli errori PHP standard dovrebbero essere considerati obsoleti. PHP fornisce una classe ErrorException integrata per convertire errori, avvisi e avvisi in eccezioni con una traccia dello stack corretta e completa. Lo usi in questo modo:

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

Usandolo, questa domanda diventa discutibile. Gli errori integrati ora generano eccezioni e quindi anche il tuo codice dovrebbe.

IMO, questo è un caso d'uso perfettamente valido per 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 questa strategia, ottieni il $errcontextparametro se lo fai $exception->getTrace()all'interno della funzione handleException. Questo è molto utile per determinati scopi di debug.

Sfortunatamente, questo funziona solo se usi trigger_errordirettamente dal tuo contesto, il che significa che non puoi usare una funzione / metodo wrapper per aliasare la trigger_errorfunzione (quindi non puoi fare qualcosa come function debug($code, $message) { return trigger_error($message, $code); }se desideri i dati di contesto nella tua traccia).

Ho cercato un'alternativa migliore, ma finora non ne ho trovato.