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?

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? 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.

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 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.