`trigger_error` vs` throw Exception` w kontekście magicznych metod PHP

Prowadzę debatę z kolegą na temat prawidłowego użycia (jeśli w ogóle) trigger_errorw kontekście magicznych metod . Po pierwsze, uważam, że trigger_errornależy tego unikać, z wyjątkiem tego jednego przypadku.

Powiedzmy, że mamy klasę z jedną metodą foo()

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

Powiedzmy teraz, że chcemy zapewnić dokładnie ten sam interfejs, ale użyj magicznej metody, aby przechwycić wszystkie wywołania metod

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

Obie klasy są takie same pod względem odpowiedzi, foo()ale różnią się przy wywoływaniu niepoprawnej metody.

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

Moim argumentem jest, że magiczne metody powinny wywoływać, trigger_errorgdy zostanie złapana nieznana metoda

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

Tak, aby obie klasy zachowywały się (prawie) identycznie

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

Mój przypadek użycia to implementacja ActiveRecord. Używam __calldo chwytania i obsługi metod, które zasadniczo robią to samo, ale mają modyfikatory takie jak Distinctlub Ignorenp

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

lub

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

Metody takie jak where(), from(), groupBy(), itd. Są zakodowane.

Mój argument jest podkreślony, gdy przypadkowo dzwonisz insret(). Gdyby moja aktywna implementacja rekordu zapisała wszystkie metody na stałe, byłby to błąd.

Jak w przypadku każdej dobrej abstrakcji, użytkownik powinien nie znać szczegółów implementacji i polegać wyłącznie na interfejsie. Dlaczego implementacja korzystająca z magicznych metod powinna zachowywać się inaczej? Oba powinny być błędem.

Weź dwie implementacje tego samego interfejsu ActiveRecord ( select(), where()etc.)

class ActiveRecord1 {
    //Hardcodes all methods
}

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

Jeśli wywołasz niepoprawną metodę w pierwszej klasie, np ActiveRecord1::insret(). Domyślnym zachowaniem PHP jest wyzwolenie błędu . Nieprawidłowe wywołanie funkcji / metody nie jest warunkiem, który rozsądna aplikacja chciałaby przechwycić i obsłużyć. Jasne, możesz go złapać w językach takich jak Ruby lub Python, w których błąd jest wyjątkiem, ale inne (JavaScript / dowolny język statyczny / więcej?) Nie powiedzie się.

Powrót do PHP - jeśli obie klasy implementują ten sam interfejs, dlaczego nie powinny wykazywać tego samego zachowania?

Jeśli wykryje __calllub __callStaticwykryje niepoprawną metodę, powinny one wywołać błąd naśladujący domyślne zachowanie języka

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

Nie spieram się, czy należy stosować błędy w stosunku do wyjątków (w 100% nie powinny), jednak uważam, że magiczne metody PHP są wyjątkiem - kalambur zamierzony :) - do tej reguły w kontekście języka

Zamierzam opublikować moją opinię, ale jeśli używasz trigger_errorgdziekolwiek, to robisz coś złego. Wyjątki to droga.

Zalety wyjątków:

• Można je złapać. Jest to ogromna zaleta i powinna być jedyną, której potrzebujesz. Ludzie mogą spróbować czegoś innego, jeśli spodziewają się, że coś pójdzie nie tak. Błędy nie dają tej okazji. Nawet skonfigurowanie niestandardowej procedury obsługi błędów nie podtrzymuje świecy, aby po prostu złapać wyjątek. Jeśli chodzi o komentarze w pytaniu, to, co to jest „uzasadniona” aplikacja, zależy całkowicie od jej kontekstu. Ludzie nie mogą wychwycić wyjątków, jeśli myślą, że w ich przypadku tak się nigdy nie stanie. Nie dawanie ludziom wyboru to Bad Thing ™.
• Układaj ślady. Jeśli coś pójdzie nie tak, wiesz, gdzie i w jakim kontekście wystąpił problem. Czy próbowałeś kiedyś wyśledzić, skąd pochodzi błąd niektórych z podstawowych metod? Jeśli wywołasz funkcję o zbyt małej liczbie parametrów, otrzymasz niepotrzebny błąd, który podkreśla początek metody, którą wywołujesz, i całkowicie pomija miejsce, z którego się ona wywołuje.
• Przejrzystość. Połącz powyższe dwa, a otrzymasz wyraźniejszy kod. Jeśli spróbujesz użyć niestandardowej procedury obsługi błędów do obsługi błędów (np. Do generowania śladów stosu dla błędów), cała obsługa błędów odbywa się w jednej funkcji, a nie w miejscu, w którym błędy są generowane.

W odpowiedzi na Twoje obawy wywołanie metody, która nie istnieje, może być uzasadnioną możliwością . Zależy to całkowicie od kontekstu pisanego kodu, ale w niektórych przypadkach może się to zdarzyć. Reagując na konkretny przypadek użycia, niektóre serwery baz danych mogą oferować pewne funkcje, których inne nie. Używanie try/ catchi wyjątków w __call()funkcji w celu sprawdzenia możliwości to zupełnie inny argument.

Jedynym przypadkiem użycia, który mogę wymyślić, trigger_errorjest użycie E_USER_WARNINGlub niższe. Wywołanie E_USER_ERRORchoć jest zawsze moim zdaniem błędem.

Standardowe błędy PHP należy uznać za przestarzałe. PHP zapewnia wbudowaną klasę ErrorException do konwertowania błędów, ostrzeżeń i powiadomień na wyjątki z pełnym odpowiednim śledzeniem stosu. Używasz go w ten sposób:

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

Dzięki temu pytanie staje się dyskusyjne. Wbudowane błędy wywołują teraz wyjątki, więc twój kod również powinien.

IMO, jest to całkowicie uzasadniony przypadek użycia dla 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);

Korzystając z tej strategii, otrzymujesz $errcontextparametr, jeśli wykonujesz $exception->getTrace()tę funkcję handleException. Jest to bardzo przydatne do niektórych celów debugowania.

Niestety działa to tylko wtedy, gdy używasz trigger_errorbezpośrednio z kontekstu, co oznacza, że ​​nie możesz użyć funkcji / metody opakowania do aliasu trigger_errorfunkcji (więc nie możesz zrobić czegoś takiego, function debug($code, $message) { return trigger_error($message, $code); }jeśli chcesz, aby dane kontekstu były w twoim śladzie).

Szukałem lepszej alternatywy, ale jak dotąd nie znalazłem żadnej.