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