Exception handling z przywracaniem, Problem użycia restore wewnątrz handler'a (PHP 7.3.4) Opcje

[session]

Witajcie!

Przejdę od razu do rzeczy:

[PHP] pobierz, plaintext 
function catchable($e) {
    if(get_class($e) === 'PDOException')
        echo 'Database problem';
 
    restore_exception_handler();
    throw $e;
}
 
function unknown($e) {
    echo 'Something went wrong';
}
 
set_exception_handler('unknown');
set_exception_handler('catchable');
 
throw new Exception('Catch me!');
[PHP] pobierz, plaintext 

Kod zwraca Uncaught Exception.

Jest to dla mnie nieoczekiwane zachowanie z kilku powodów:
1. Nie ma przeciwwskazań do wywoływania innych funkcji (również user-defined) z samego callback'a
2. set_exception_handler wywołany z poziomu handler'a zwraca prawidłową nazwę callback'a, co oznaczałoby że ma dostęp do bieżącego stosu handler'ów
3. throw ostatecznie się wykonuje i dopiero domyślny handler kończy działanie
4. użycie restore_exception_handler poza handler'em daje oczekiwany rezultat

Nie wiem zatem czy jest to problem języka, mojej interpretacji zachowania tych funkcji, czy rodzaj zabezpieczenia przed pętlą wyjątków. W dodatku myślę, że w przypadku error'ów może dziać się analogicznie.
Macie może jakieś sugestie, dlaczego wyjątek nie trafia do poprzedniego handler'a? Jakieś alternatywy dla tej funkcjonalności (poza wywoływaniem unknown na końcu catchable)?

A komu to potrzebne?
Sam fragment kodu to oczywiście koncepcja. Zamiarem jest, aby każda klasa, w której będzie to potrzebne, posiadała odrębny handler, w którym obsługiwane będą wyjątki związane z tą klasą. Natomiast główny handler aplikacji wyłapywałby wszystkie pozostałe wyjątki, tak aby zakończyć działanie w bardziej wdzięczny sposób, niż robi to domyślny handler.

EDIT: Znalazłem jeszcze notatkę sprzed 5 lat. Jak zatem rozwiązujecie obsługę wyjątków i błędów w aplikacji, tak aby handling był rozproszony? Gotta catch 'em all? (IMG:style_emoticons/default/tongue.gif)

Ten post edytował session 17.04.2019, 02:38:07

[viking]

A czemu nie zrobisz tego po prostu w odpowiednich namespace? jeśli pakiet to Cos, to klasy wyjątków w Cos\Exception. Łapanie wszystkich będzie pewnie i tak na poziomie index.php, a reszta tam gdzie wywołujesz klasę.

[session]

Nie bardzo wiem jak można by tutaj wykorzystać namespace'y? (IMG:style_emoticons/default/worriedsmiley.gif) Może opiszę to jeszcze od innej strony. Chciałbym zrobić jakiś wygodny exception handling, try/catchowanie tych samych wyjątków w wielu metodach jest dla mnie mało efektywne. W dodatku semantycznie przydatny byłby wielopoziomowy handling:

[PHP] pobierz, plaintext 
class Database {
    public function __construct(){
        set_exception_handler([$this, 'exceptionHandler']);
    }
 
    public function select(){}
    public function insert(){}
    public function update(){}
    public function delete(){}
 
    public function exceptionHandler($e){
        restore_exception_handler();
        throw $e;
    }
}
 
class User {
    public function __construct(){
        set_exception_handler([$this, 'exceptionHandler']);
    }
 
    public function add(){ $db = new Database(); $db->insert(); }
 
    public function exceptionHandler($e){
        restore_exception_handler();
        throw $e;
    }
}
 
set_exception_handler('unknown');
[PHP] pobierz, plaintext 

I wtedy wszystkie wyjątki związane z bazą danych obsługiwane w klasie Database, a wyjątki z klasy User z fallback'iem do Database. Finalnie wszystkie pozostałe wyjątki obsługiwane przez kolejny handler.
Teoretycznie myślę, że można by zrobić customowy stos handler'ów, callback'i, metody set i restore i wykorzystać tylko jeden "oryginalny" handler, ale czy nie byłby to pewnego rodzaju overkill?
Dziwi mnie, że PHP który na kilku stronach manual'a pokazuje wykorzystanie wielu set i restore w tym przypadku nie działa w oczekiwany sposób. (IMG:style_emoticons/default/blink.gif)

Ten post edytował session 17.04.2019, 11:23:30

[viking]

Tak z ciekawości. Jak w tej swojej klasie database obsłużysz np transakcje i rollbacki? W klasie User nie powinieneś tworzyć obiektu Database tylko go wstrzyknąć. Bardziej mi to wygląda na problem z architekturą tej aplikacji.

[session]

Ok, nie najlepszy przykład może, tak na prawdę Database byłaby singleton'em i bardziej statyczna, ale wtedy konstruktor nie miałby sensu, więc trochę dla uproszczenia poszedłem na skróty na potrzeby przykładu (IMG:style_emoticons/default/wink.gif) Jednak dalej zastanawiają mnie te wyjątki, tym bardziej, że PHP od 7. wersji coś w tej tematyce ogólnie zmieniał.

Ten post edytował session 17.04.2019, 12:19:44

[viking]

https://www.php.net/manual/en/language.errors.php7.php
Możesz wiele wyjątków na raz przez | łapać. Na pewno nie żaden singleton i na pewno nie więcej statyków tylko dependency injection. A czepiam się tego bo wyraźnie to pokazuje że masz problem z architekturą całości i prawidłowym grupowaniem funkcjonalności w zestaw klas.