w jaki sposob debugujecie skrypty ?

w php znam 2 sposoby:
1. Edytor z debugerem
2. Skrypt php z wlasna obsluga bledow

z pierwszym mam problem
mam edytor php Coder Pro -> http://phpide.de ->
debugger -> http://dd.cron.ru

najnowsza wersja mi nie dziala i mam komunikat zeby zgrac 2.04 - ale 2.04 tez mi nie chodzi - nie moze zaladowac bibloiteki

na PHPEdit dziala mi debugger -> http://phpedit.net
ale za to phpedit czesto mi sie wiesza i nie dziala wiele rzeczy (np undo) mimo iz zgralem stable 6.0

PHPEd - nie testowalem jeszcze

Zend Studio - za wolne na moim kompie :-)

wiecej dobrych edytorow z mozlowoscia debugowania chyba nie ma ?

2. drugi sposob za pomoca skryptow
napisalem niedawno taki 1
na razie tylko pare najpotrzebineszych rzeczy zaimplementowalem

http://scg.milc.com.pl/cagret/debug/lib.mgcError.php

a tutaj przyklad:

http://scg.milc.com.pl/cagret/debug/test.php

- wypisuje blad
- kod gdzie byl blad
- wartosci zmiennych z tego kawalka kodu (mozliwosc ograniczenia zaglebienia petli)
- limit bledow

mam zamiar dodac jeszcze pare funkcji zeby zabezpieczyc sie pzred "hackingiem"
- mozliowsc zapisywania bledow do pliku
- lub na maila wyslanie
- Ip osoby, data etc
- ignorowanie bledow (nie wypisze uzytkownikowi)

stosujecie takie zabezpieczenia na swoich stronach ?
(zlapie sie lamerkow ktorzy probuja podstawiac pod zmienne jakies wartosci i wylapywac bledy w kodzie)

Jeśli chodzi o wymienione przez Ciebie sposoby debugowania skryptów, to ten drugi jest zdecydowanie bardziej wszechstronny.

Przejrzałem na razie pobieżnie tą Twoją bibliotekę i muszę przyznać, że jestem pod wrażeniem. Kawał dobrej roboty. Musiał bym się przyjrzeć jak to wypada w porównaniu do klas PEAR i PEAR_Error. A swoją drogą, ciekawe że zdecydowałeś się pisać klasę od zera, a nie rozbudowywać PEAR_Error.

Jeśli chodzi o zapisywanie błędów do plików, albo wysyłkę na maila, to proponuję wydzielić w ogóle tablicę z uchwytami 'standardowych wyjść' klasy mgcError. Można by wtedy dopisywać kolejne metody eksportu danych (ekran, płaski plik logów, plik logów w formie XML, zapis do bazy, wysyłka mailem itd.) przeciążając klasę i tylko rejestrować w tablicy te uchwyty, które mają zostać użyte.

jest jeszcze trzeci znany mi sposob:
3. dupczenie

stosowanie: w krytycznym dla nas fragmencie kodu piszemy

zadzwijaco skuteczne ;)

Chyba że nie wiemy co okaże się krytycznym fragmentem kodu. Sami nie wychwycimy wszystkich błędów. System obsługi błędów z logowaniem do plików pozwala wykryć błędy które wystąpiły podczas używania naszych skryptów przez kogoś innego.

Ja także jestem pod wrażeniem twojego skryptu cagrET... Mimo że ja także piszę własną, to twoja w porównaniu z moją jest duuuużo lepsza

Ja poprostu wyłaczam pokazywanie blędów na WWW, a wszystkie błędy ślę sobie na mejla stare - dobre - niezwodne

jak chcecie wiecej gosu kodu to tutaj mozna zlookac ;-)

http://www.php-editors.com/results_b1.php

a tutaj moj ;-)

http://www.php-editors.com/hlight_script.p...php?show=cagret

Sorki, że się wtrącam, ale słyszeliście o metodologii eXtreme Programming? W necie krązy wiele materiałów o tym podejściu do kodowania - poczytajcie artykuły na extremeprogramming.com, http://www.phppatterns.com/index.php/artic...cleview/33/1/2/ (dość prymitywny przykład, ale zawsze w php) itp.

Poprzez tworzenie skryptów testujących serwis możecie symulować akcje, które użytkownik normalnie wykonuje przez przeglądarkę. Przy dobrze zaprojektowanym serwisie nie powinno to być takie trudne - trzeba po prostu odpowiednio uogólniać interfejs, aby w razie czego umożliwić użycie tzw. Mock Objects, czyli obiektów, które imitują środowisko w postaci bazy danych (np. na zapytanie zwracają cały czas te same dane, które po przetworzeniu przez obiekt testowany skrypt testujący porównuje z oczekiwanymi), kontrolerów, które zamiast domyślnie przekazywanych danych z GET i POST przekażą dane wzorcowe itp. Dla 'niewtajemniczonych' zapewne brzmi to zabójczo, ale naprawdę sprawdza się! ))

Podejście jest trochę inne - przeważnie testy tworzy się przed napisaniem skryptu, który będziemy testować, co może wydawać się szalone, ale jest doskonałym pomysłem, gdyż zmusza do myślenia obiektowego i pozwala na lepsze zaprojektowanie aplikacji i jej warstw (dane [Model] - logika [Controller] - prezentacja [View]) poprzez jasne określenie interfejsu. Może się to wydawać trudne i bezsensowne, ale daje sporo frajdy, gdyż po prostu ukazuje nam do czego zmierzamy i wyznacza granice, których mamy się trzymać.

Jeśli do tego dodamy porządną obsługę błędów, która będzie w końcu dostępna wraz z PHP5 to (imho) takie skrypciki bazujące na pojedynczych handlerach po prostu tracą sens ;P

cagrET: Odnośnie Twojej klasy... jakiej wersji php ona wymaga? Ja mam 4.1.2 i załączając klasę wypisuje mnie, że nie może jej ustawić (Couldnt set error handler) ;(

polecam magume. Ma wszystkie przydatne opcje (class browser, generowanie opisów, functions browser) plus dużo więcej i na dodatek ma debugowanie skryptów.

w domu 4.3.1

ale ten link jest do skryptu na servie na ktorym jest wersja 4.1.2
wiec nie wiem co moze byc problemem

Teraz używam czegoś takiego: http://prdownloads.sourceforge.net/mygosuc...er.zip?download

Przykład wyświetlania błędu: http://www.gosu.pl/demo/ErrorHandler/example1.html
Przykład wyświetlania źródła pliku w którym błąd wystąpił: http://www.gosu.pl/demo/ErrorHandler/example2.html

Wyświetlanie błędu: debug_backtrace(), plik / linia , funkcja / argumenty, źródło pliku

Hint: numerowanie linii ci się rozjeżdża, gdy jakaś linia kodu jest zbyt długa i przeglądarka zawija wiersze.
Dobre rozwiązanie tego problemu opublikowałem na forum php-editors.com.

Ja używame php5 i tam jest wbudowana dobra obsługa błędów ! W moim skrypcie debugowanie ogranicza się do zapisania wyniku do logu i po wszystkim, w logu umieszczam wszelkie dane potrzebne do rozwiązania problemu.

PS. Podoba mi się ta klasa do obsługi błędów , ale na php4 .

Ale wracam. Co sądzicie o rozwiązaniu zastosowanym w php5, wg mnie to znacznie ułatwia wyszukiwanie i obsługe wyjątków w skrypcie.