Mi się podoba, chociaż to raczej pisałes dla ćwiczeń, bo używać tego nikt raczej nie będzie
W każdym razie jak zwykle ładnie opisane i jest przykład. Byle dalej

@sopel : Uzylem swoich trzech bo na dzialanie tego debuggera bez sensu byloby uzywanie dyrektyw E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING, E_STRICT ktorych nie bede uzywal poki co ( jesli brac pod uwage wersje 1.0.0 ). Pozatym mysle ze sposob w jaki dziala ten debugger i jego przeznaczenie do tworzenia komunikatow error, wran, notice przez piszacego skrypt (klasa nie przechwutuje bledow parsera php) bylo akurat odpowiednie. Moze moj sposob myslenia jest zly ale przemysle twoja uwage. Dzieki

@tes : dla cwiczen moze nie, beda z tego korzystac nowe wydania klas class5, na ktorych bedzie oparty miedzy innymi FileSupply Pro 2.0.0 oraz EclipseX

Debugger to cos w stylu Obsługa Wyjatków?

W przykladach jakie tu sa, chyba widac po co to jest. Wyobraz sobie ze masz klase obslugujaca np baze danych i ona ma np funkcje ->query('SELECT....') , w wyniku tego zapytania wystapil jakis blad - i teraz zamiast wyrzucac print 'Blad zapytania', dajesz do debuggera, ktory nie dosc ze pokaze w zgrabny sposob kod bledu i przygotowana przez ciebie tresc - to w dodatku przesledzi w ktorym dokladnie miejscu (plik , linia) nastapilo wywolanie ->query(...) i przesledzi co jak i ktoredy - przyjzyj sie dokladnie przykladowi 1 gdie wywolanie add_event nastpilo w funkcji bar() , ktora zostaje wywolana przez foo(), a ta natomiast gdzies w zrodle

Czyli Debugger == Error Handler.

nie zupelnie, z tego co sie orientuje error_handler przechwutuje bledy php E_ERROR etc, tutaj sam definiujesz w ktorym miejscu nastapi dodanie watku add_event().

No tak, ale od "własnych" bledow sa wyjatki.

nie przewiduje narazie takich :] hyhyh - a na powaznie myslalem o tym - i na pewno pojawi sie w kolejnym relase.

Dobry pomysł ale niestety, w praktyce trudny do wykorzystania. Po pierwsze, nie zastąpi on w pełni debuggera takiego jak ma np. php Eclipse, gdzie krok po kroku można się poruszać pomiędzy breakpointami, gdzie od razu widać zmienne, jakie trafiły do funkcji oraz zrzut tablic superglobalnych.
Coś takiego jest bardzo trudne do uzyskania przy użyciu Twojej klasy i szczerze wątpie by mimo dobrych opini ktoś jej używał przy pisaniu. Mi np. o wiele wygodniej kliknać na marginesie i odpalić debuggera w moim IDE niż wpisywać kolejne linie kodu.
Przykład który podałeś nie sprawdzi się również w praktyce ponieważ na serwerze produkcyjnym nie będziesz chciał takiej informacji pokazywać ze względów bezpieczeństwa. Użytkownik w takiej sytuacji powinien dostać wiadomość, że operacja się nie powiodła a nie stack trace. Takie sytuacje powinno się załatwiać loggerami - w javie wielką popularnością cieszy się pakiet common.logging albo Log4J (powstały również porty do php). Logi odkładają się w jednym miejscu, gdy w gotowej aplikacji wystąpi błąd programista zagląda do logów i analizuje, diagnozuje przyczynę błędu. Oczywiście nie zawsze takie rozwiązanie jest dobre.
Nie wiadomo czym ta klasa ma być - czy kolejnym error handlerem czy czymś innym? Jako exception handler nie zda się, ponieważ po wykonaniu exception handlera php i tak kończy pracę. Kończąc - mimo dobrego wykonania - po prostu nie widzę zastosowania dla tej klasy.

splatch: ciekawa opinia - ale niestety / na szczescie ja widze zastosowanie dla siebie i wcale nie sadze badz nie propaguje by uzywal tego ktokolwiek inny niemniej chcialem oceny - wiec i taka sie liczy . dzieki.

-- added

pozatym gdzie jest powiedziane ze praca tej klasy musi byc jawna, w 2 przykladzie pokazano ze wcale tak nie musi byc

Poza tym mamy jeszcze funkcje: trigger_error i set_error_handler...

Bardzo dobrze napisany kod, ale zgodzę się ze splatch'em, że z zastosowaniem tego będzie problem. Tak klasa jednocześnie robi za dużo i za mało.

Za dużo, bo w jednej klasie jest łapanie zdarzeń, formatowanie przechwyconej wiadomości, tworzenie backtrace, wyrzucanie HTMLa. Przez to cały system staje się niekonfigurowalny. Mogę chcieć przecież zapisać opis do pliku czy nawet zmienić wygląd tworzonego HTMLa. Dorabianie na tę okoliczność kolejnych parametrów będzie złym pomysłem, bo już te, które są, można zastąpić dobrym rozbiciem na obiekty.

Za mało, bo informacje przedstawione na ekranie są ubogie. Oczywiście, jest ładnie sformatowany backtrace, ale PHP5 potrafi znacznie, znacznie więcej. Cała biblioteka Reflection idealnie nadaje się do takich zastosowań.

hawk mysle ze masz duzo racji - po przemysleniu sprawy ze splatchem tez sie zgodze.
klasa jednak powstaje na moj specjalny uzytyek do CMS'a (nastepcy SiteX) i dzieki waszym
opiniom bedzie jeszcze jeszcze jeden relase, ktory pozowoli mi na dobor optymalnych parametrow jej pracy. Jeszcze raz dziekuje