Temat: kontrola błędów sql

mam klasę do obsługi bazy danych, która w funkcji query zwraca wskaźnik wyniku lub false w przypadku błędu.
używam jej zwykle w ten sposób (kod uproszczony):

if(!$result = $db -> query(''))
error('bład bazy danych');

ponieważ w 99.9% przypadków błąd bazy jest dla mnie błędem krytycznym zastanawiałem się nad użyciem wyjątków w samej klasie db.

czyli:
function query($sql_query)
{
if !mysql_query($sql_query)
throw new Exception DatabaseException(jakies dane np. $sql_query);
}

w kodzie głównym gdzie używałbym $db-> query nie pisałbym żadnego if tylko try i to tylko w momencie gdy chciałbym zrobić coś innego niż przerwać program.
natomiast wszystkie tego typu błędy chciałbym złapać przez oddzielną funkcję ustaloną przez set_exception_handler()

i tu moje pytania :
1. czy da się w funkcji set_exception_handler łapać konkretny typ wyjątku ?
2. albo mieć oddzielny exception handler dla każdego typu wyjątku (tak jak można mieć kilka sekcji catch)

3. jak Wy to robicie ? piszecie 10000 razy if albo try za kazdym razem jak robicie zapytanie do bazy danych ?

ew. jeszcze mogę dodać do funkcji query dodatkową zmienną określającą zachowanie w przypadku błędu.
np. function query($sql_query, $throw_error = true)
{
}Krzysztof D. edytował(a) ten post dnia 24.05.12 o godzinie 19:18

Temat: kontrola błędów sql

Krzysztof D.:
mam klasę do obsługi bazy danych, która w funkcji query zwraca wskaźnik wyniku lub false w przypadku błędu.
używam jej zwykle w ten sposób (kod uproszczony):

if(!$result = $db -> query(''))
error('bład bazy danych');

Nie uważasz że to troszkę bez sensu ? Nie licząc sytuacji newralgicznych jak np pobranie uprawnień albo danych użytkownika, większość tego co wyświetlamy na ekranie jest kompletnie ZBĘDNA. Co za tym idzie - jeżeli baza zwróciła błąd, ten fakt powinien być gdzieś zalogowany (nietrudno to wykryć w końcu a jeszcze łatwiej zrzucić dane do pliku albo psiakoś inaczej ) a aplikacja powinna działać dalej bez wiedzy użytkownika.
Ewentualnie po zalogowaniu przekierowujesz na stronę z komunikatem że coś się sypnęło a stado tresowanych małp już się tym zajmuje :) (patrzę na Ciebie youtube)

ponieważ w 99.9% przypadków błąd bazy jest dla mnie błędem krytycznym zastanawiałem się nad użyciem wyjątków w samej klasie db.

O ile wiem można PDO skonfigurować by wyrzucało wyjątki więc to żaden problem.

czyli:
function query($sql_query)
{
if !mysql_query($sql_query)
throw new Exception DatabaseException(jakies dane np. $sql_query);
}

w kodzie głównym gdzie używałbym $db-> query nie pisałbym żadnego if tylko try i to tylko w momencie gdy chciałbym zrobić coś innego niż przerwać program.

To nie prościej zrobić dekorator dla PDO czy co tam używasz i wyposażyć go w wyłapywanie i logowanie błędów ?

natomiast wszystkie tego typu błędy chciałbym złapać przez oddzielną funkcję ustaloną przez set_exception_handler()

Pytanie - czy to mądre ? set_exception_handler nadpisze Ci zachowanie dla WSZYSTKICH wyjątków. To jak celowanie w muchę z armaty.

i tu moje pytania :
1. czy da się w funkcji set_exception_handler łapać konkretny typ wyjątku ?

Exception handler łapie WSZYSTKIE wyjątki a funkcja którą rejestrujesz ma 1 parametr - obiekt wyjątku. Wystarczy sprawdzić z jakim mamy do czynienia.

2. albo mieć oddzielny exception handler dla każdego typu wyjątku (tak jak można mieć kilka sekcji catch)

Po co Ci oddzielny exception handler ? Od tego masz wzorzec strategię.

3. jak Wy to robicie ? piszecie 10000 razy if albo try za kazdym razem jak robicie zapytanie do bazy danych ?

Pewnie że nie. Dobrze napisana obsługa bazy danych nie powinna się wysypać nawet jak baza danych się wysypie. Są 2 punkty w których coś się rypnie. Połączenie z bazą danych bądź zapytanie. Jeżeli połączenie to już na starcie dajesz stronę błędu jeżeli baza danych jest wymagana. Jeżeli zapytanie to po prostu zwracasz pusty wynik logując błąd gdzieś ( np mój mechanizm zapisuje błędy aplikacji do pliku którego nazwa to data wystąpienia błędu + wysyła email do mnie ). Drugi przypadek w przetestowanej aplikacji raczej nie występuje. No jeszcze baza może być przeciążona ale to już inna para kaloszy.

ew. jeszcze mogę dodać do funkcji query dodatkową zmienną określającą zachowanie w przypadku błędu.
np. function query($sql_query, $throw_error = true)
{
}

Nie tędy droga. Zamaskowanie błędu ni rozwiąże problemu i wydłuży czas naprawy bo nie zostanie on szybko zauważony. Użyj dekorator, dopisz logowanie i zadbaj by po prostu w wypadku błędu zwracane były puste wyniki a aplikacja powinna być zrobiona tak by sobie z tym radzić.Dariusz Półtorak edytował(a) ten post dnia 24.05.12 o godzinie 19:42

Temat: kontrola błędów sql

Dariusz Półtorak:

Krzysztof D.:
mam klasę do obsługi bazy danych, która w funkcji query zwraca wskaźnik wyniku lub false w przypadku błędu.
używam jej zwykle w ten sposób (kod uproszczony):

if(!$result = $db -> query(''))
error('bład bazy danych');

Nie uważasz że to troszkę bez sensu ? Nie licząc sytuacji newralgicznych jak np pobranie uprawnień albo danych użytkownika, większość tego co wyświetlamy na ekranie jest kompletnie ZBĘDNA. Co za tym idzie - jeżeli baza zwróciła błąd, ten fakt powinien być gdzieś zalogowany (nietrudno to wykryć w końcu a jeszcze łatwiej zrzucić dane do pliku albo psiakoś inaczej ) a aplikacja powinna działać dalej bez wiedzy użytkownika.
Ewentualnie po zalogowaniu przekierowujesz na stronę z komunikatem że coś się sypnęło a stado tresowanych małp już się tym zajmuje :) (patrzę na Ciebie youtube)

moja funkcja error wyświetla błąd dla użytkownika w postaci bardzo generalnej, typu "wystąpił błąd". wygląd jest generowany przez parser, a nie jest to zwykły tekst. W zależności od tego gdzie wystąpił błąd, jest np. przycisk do zamknięcia okna lub link przekierowujący do strony głównej (czy gdzie indziej).
bład jest przesyłany mailem lub zapisany do sysloga lub do pliku tekstowego poza poziomem dostępu przez url.
w funkcji error uzywam backtrace, loguję zmienne, itp.
podsumowując nie jest to zwykle echo $error.

ponieważ w 99.9% przypadków błąd bazy jest dla mnie błędem krytycznym zastanawiałem się nad użyciem wyjątków w samej klasie db.

O ile wiem można PDO skonfigurować by wyrzucało wyjątki więc to żaden problem.

nie używam PDO. mam aplikację w której ściśle jest ustalony jest typbazy danych, poza tym od tego mam plik z klasą db, tak więc ew. mogę dopisać kolejną wersję pliku gdybym musiał skorzystać z innej bazy, co jest mało prawdopodobne.

czyli:
function query($sql_query)
{
if !mysql_query($sql_query)
throw new Exception DatabaseException(jakies dane np. $sql_query);
}

w kodzie głównym gdzie używałbym $db-> query nie pisałbym żadnego if tylko try i to tylko w momencie gdy chciałbym zrobić coś innego niż przerwać program.

To nie prościej zrobić dekorator dla PDO czy co tam używasz i wyposażyć go w wyłapywanie i logowanie błędów ?

nie używam PDO.

natomiast wszystkie tego typu błędy chciałbym złapać przez oddzielną funkcję ustaloną przez set_exception_handler()

Pytanie - czy to mądre ? set_exception_handler nadpisze Ci zachowanie dla WSZYSTKICH wyjątków. To jak celowanie w muchę z armaty.

myślałem o exception handler który jest w stanie zweryfikować typ exception. w końcu nie chcę pokazywać szczegółów błedów użytkownikowi. dla błedów sql miałbym inne zachowanie, dla innych inne.

poza tym nie dla wszystkich wyjątków tylko nie złapanych przez try/catch.

i tu moje pytania :
1. czy da się w funkcji set_exception_handler łapać konkretny typ wyjątku ?

Exception handler łapie WSZYSTKIE wyjątki a funkcja którą rejestrujesz ma 1 parametr - obiekt wyjątku. Wystarczy sprawdzić z jakim mamy do czynienia.

instanceof ?

2. albo mieć oddzielny exception handler dla każdego typu wyjątku (tak jak można mieć kilka sekcji catch)

Po co Ci oddzielny exception handler ? Od tego masz wzorzec strategię.

?

3. jak Wy to robicie ? piszecie 10000 razy if albo try za kazdym razem jak robicie zapytanie do bazy danych ?

Pewnie że nie. Dobrze napisana obsługa bazy danych nie powinna się wysypać nawet jak baza danych się wysypie. Są 2 punkty w których coś się rypnie. Połączenie z bazą danych bądź zapytanie. Jeżeli połączenie to już na starcie dajesz stronę błędu jeżeli baza danych jest wymagana. Jeżeli zapytanie to po prostu zwracasz pusty wynik logując błąd gdzieś ( np mój mechanizm zapisuje błędy aplikacji do pliku którego nazwa to data wystąpienia błędu + wysyła email do mnie ). Drugi przypadek w przetestowanej aplikacji raczej nie występuje. No jeszcze baza może być przeciążona ale to już inna para kaloszy.

>

i o to mi chodzi.
sęk w tym, że czasem gdy baza np. padnie, albo ulegnie uszkodzeniu tabela,
czasem łączę się z zdalną tabelą i mogę stracić połączenie,

to potrzebuję jednak zrobić coś jeszcze niż tylko wygenerować błąd i przerwać wszystko.
stąd generowanie błędu na poziomie klasy db mi nie pasuje.

ew. jeszcze mogę dodać do funkcji query dodatkową zmienną określającą zachowanie w przypadku błędu.
np. function query($sql_query, $throw_error = true)
{
}

Nie tędy droga. Zamaskowanie błędu ni rozwiąże problemu i wydłuży czas naprawy bo nie zostanie on szybko zauważony. Użyj dekorator, dopisz logowanie i zadbaj by po prostu w wypadku błędu zwracane były puste wyniki a aplikacja powinna być zrobiona tak by sobie z tym radzić.

patrz post niżej + nie chcę mieć co chwilę poza klasą db obsługi błędów bazyKrzysztof D. edytował(a) ten post dnia 24.05.12 o godzinie 22:16

Temat: kontrola błędów sql

podsumowując poprawiam system który pisałem x lat temu dla php4.
chcę mieć zunifikowany sposób generowania błędów bazy danych, które występują raz na 100 lat.
czyli nie chcę tysiąc razy pisać if lub try przy wykonywania zapytania w głównym kodzie programu, a w klasie db.

przy czym nie chcę wciskać w klasę db generowania błędu, gdyż potrzebuję w kilku przypadkach jednak zrobić coś niż tylko wygenerować błąd.

mam do wyboru albo mieć zmienną kontrolną w funkcji query decydującą czy wygenerować błąd w klasie czy go samemu obsłużyć, albo skorzystać z wyjątków i obsługiwać je jako niewyłapane w 99.9% przypadków i w momentach gdzie jest dla mnie istotna specjalna obsługa błędu skorzystać z try/catch

Temat: kontrola błędów sql

Dariusz Półtorak:

Krzysztof D.:
mam klasę do obsługi bazy danych, która w funkcji query zwraca wskaźnik wyniku lub false w przypadku błędu.
używam jej zwykle w ten sposób (kod uproszczony):

if(!$result = $db -> query(''))
error('bład bazy danych');

Nie uważasz że to troszkę bez sensu ? Nie licząc sytuacji newralgicznych jak np pobranie uprawnień albo danych użytkownika, większość tego co wyświetlamy na ekranie jest kompletnie ZBĘDNA.

Poinformowanie użytkownika o błędzie zapisu w bazie danych uważasz za... zbędne??? Powiedz, że żartujesz...

Temat: kontrola błędów sql

Andrzej Prażmo:

Dariusz Półtorak:

Krzysztof D.:
mam klasę do obsługi bazy danych, która w funkcji query zwraca wskaźnik wyniku lub false w przypadku błędu.
używam jej zwykle w ten sposób (kod uproszczony):

if(!$result = $db -> query(''))
error('bład bazy danych');

Nie uważasz że to troszkę bez sensu ? Nie licząc sytuacji newralgicznych jak np pobranie uprawnień albo danych użytkownika, większość tego co wyświetlamy na ekranie jest kompletnie ZBĘDNA.

Poinformowanie użytkownika o błędzie zapisu w bazie danych uważasz za... zbędne??? Powiedz, że żartujesz...

Proszę przeczytać uważnie jeszcze raz to co napisałem. Jest Pan dorosłym człowiekiem więc nie powinno być problemu.

Nie licząc sytuacji newralgicznych (...),
większość tego co wyświetlamy na ekranie jest kompletnie
ZBĘDNA

Mówiłem o tym że sypanie błędami w momencie gdy wywali się zapytanie nie ma sensu. W wypadku zapisu informacja jest niezbędna ale np jeżeli nie wczytano komentarzy do tekstu to nic się nie dzieje i program powinien iść dalej swoją drogą. Jedyne co się powinno stać to program powinien spisać log i zawiadomić administratora poprzez email albo w jakiś inny sposób o tym że coś się wysypało.
Jeżeli błąd dotyczy czegoś ważnego to do normalnego komunikatu można dodać np że brak owych informacji wynikł z technicznych problemów i pojawią się one niebawem. Bez wdawania się w szczegóły.

Temat: kontrola błędów sql

Dariusz Półtorak:

Nie licząc sytuacji newralgicznych (...),
większość tego co wyświetlamy na ekranie jest kompletnie
ZBĘDNA

Większość? A można prosić o definicję tej zbędnej większości w przypadku błędów, na które napotkał interpreter PHP? Może chociaż malutki przykład...?

Temat: kontrola błędów sql

Andrzej Prażmo:

Dariusz Półtorak:

Nie licząc sytuacji newralgicznych (...),
większość tego co wyświetlamy na ekranie jest kompletnie
ZBĘDNA

Większość? A można prosić o definicję tej zbędnej większości w przypadku błędów, na które napotkał interpreter PHP? Może chociaż malutki przykład...?

Pewnie że mogę skoro tak trudno Ci pomyśleć nad sytuacją. Myślałem że to proste. Jest sobie taki portal gry-online.pl. Mój znajomy non stop z niego korzystał kiedy byliśmy na studiach. Uwielbia gry i zawsze sprawdza co nowego jest na rynku kiedy ma ochotę coś kupić.
Jak studiowałem z nim kiedyś 3 lata tak nigdy nie widziałem żeby korzystając z tej strony zaglądał w inne miejsce jak "Encyklopedia", informacje o grach PO premierze (coś co ma być go nie interesowało) i informacje o promocjach. + korzystał z wyszukiwarki

Tutaj masz zrzut z obecnej strony gry-online.pl




To prosty użytkownik który ma stronę do sprawdzania aktualnych gier. Jeszcze jak mieli stary layout to byłem pod wrażeniem że znajomy klikał w klinki... zanim obrazki które były jako te linki i które pozwalały je identyfikować się pojawiały na stronie. Zawsze robił konkretną rzecz i zawsze idealnie pamiętał pozycję każdego elementu. Działał na pamięć.

Na czerwono zaznaczyłem Ci te informacje których ewentualny brak nawet nie zwrócił by jego uwagi. Elementy te nie mają wpływu na resztę strony, nie są treścią w jakikolwiek sposób niezbędną itp. Brak jakiegokolwiek z tych bloków nie zwrócił by jego uwagi.

Błąd w zapytaniu ? Timeout ? Nie pokazujesz danej sekcji a użytkownik który nie jest dokładnie tym miejscem zainteresowany niczego nie zauważa. Strona nie sypie błędami czy jakimiś na ogół niezrozumiałymi dla użytkownika komunikatami a w momencie wystąpienia owego błędu administrator strony / programista się nią zajmujący już czyta że w tym i tym miejscu pojawił się błąd taki i taki.

Wszyscy zadowoleni.

PS: w wypadku GoldenLine dla mnie brak czegoś z tego co widzę po wejściu na stronie nie będzie przeszkadzał:
~ sugerowane kontakty
~ oferty pracy
~ teraz rekrutują
~ pracodawcy
~ najnowsze dyskusje
~ komunikaty z tablicy inne niż cytaty mojej wypowiedzi

O ile jedna z tych rzeczy w którymś punkcie może mnie zainteresować o tyle na ogół chwilowy brak jednej z tych opcji nie wpłynie w żaden sposób na moje doświadczenia związanie z korzystaniem ze strony.

To tylko dane wyświetlane. Pierwszy lepszy przykład ze strony głównej. Lista tego jest znacznie dłuższa. Wszystko co nie jest niezbędne do działania strony może być chwilowo niedostępne. Skoro jest błąd to treść jest tak czy siak niedostępna ale nie widzę powodu by o takich rzeczach informować użytkownika. EWENTUALNIE można gdzieś rzucić komunikat że jakaś sekcja strony "jest niedostępna z powodu prac konseracyjnych" ale rzeczy typu "baza danych się wysypała", "nie można zapisać czegoś tam" itp itd etc nie są użytkownikowi potrzebne jeżeli system logowania błędów jest wystarczający.

Żeby zrobić mechanizm wręcz idealny jedyne co dzisiaj np językowi PHP brakuje to możliwość nadpisania handlera dla błędów skryptu (czyli tam gdzie np coś się stało z plikiem na serwerze i skrypt po prostu wywala się z uwagi na błędy składni itp) ale to podobno ma być pokryte. Dzisiaj można pokryć większość błędów aplikacji (notice, warning, error, user notice, user warning, user_error itp...), wyjątków (można nadpisać cały mechanizm obsługi wyjątków), bazy danych (to chyba jasne) itp tak że nawet jak pojawi się poważniejszy błąd - użytkownik dostanie tylko miłą informację o pracach konserwacyjnych albo stronę-mapę która z której może przejść do innej części serwisu a odpowiednie osoby zostaną natychmiast powiadomione o naturze błędu. A w wypadku wyświetlanych treści bardzo często w ogóle użytkownik nie zauważy że coś się stało jeżeli nie był daną sekcją szczególnie zainteresowany.

Mam nadzieje że to wyczerpało Twoje pytania.Dariusz Półtorak edytował(a) ten post dnia 25.05.12 o godzinie 17:02

Temat: kontrola błędów sql

Dariusz Półtorak:
Żeby zrobić mechanizm wręcz idealny jedyne co dzisiaj np językowi PHP brakuje to możliwość nadpisania handlera dla błędów skryptu (czyli tam gdzie np coś się stało z plikiem na serwerze i skrypt po prostu wywala się z uwagi na błędy składni itp) ale to podobno ma być pokryte.

jest kilka opcji (mających swoje wady):

http://stackoverflow.com/questions/1900208/php-custom-...
https://barelysufficient.org/2011/03/catching-fatal-err...

wracając do tematu zatem, co u Ciebie zajmuje się generowaniem akcji obsługi błędu ?
klasa db, klasa żądająca dane, czy jeszcze inaczej ?
używasz wyjatków, błędów, systemu z php czy własnego ?Krzysztof D. edytował(a) ten post dnia 25.05.12 o godzinie 18:53

Temat: kontrola błędów sql

btw. pomysł dalszego generowania strony pomimo błędu z totalnym olaniem informowania użytkownika jest ciekawy.
zastanawiam się na ile warty rozważenia w systemie do edycji danych (a tylko takimi się zajmuję).
pomyślę nad tym.

Temat: kontrola błędów sql

Krzysztof D.:
btw. pomysł dalszego generowania strony pomimo błędu z totalnym olaniem informowania użytkownika jest ciekawy.
zastanawiam się na ile warty rozważenia w systemie do edycji danych (a tylko takimi się zajmuję).
pomyślę nad tym.

Na pewno odpada to przy wszystkich intranetach, aplikacjach webowych itp itd etc z uwagi na to że tam raczej nie spotkasz elementów widoku które są zbędne. Więc jak coś się wysypie to tak czy siak jest to problem. Za to wszystkie witryny "publiczne", społecznościówki itp - rozwiązanie bardzo dobre pod warunkiem że mamy na prawdę dobry mechanizm logowania błędów który dostarczy nam niezbędne informacje.

Obsługa błędów jest wielostopniowa. Mam ustawiony error handler i exception handler które zajmują się sytuacjami wyjątkowymi. Ich zadaniem jest logowanie zdarzenia, zawartości tablic superglobalnych, backtrace itp.
Żeby nie robić dużych raportów mechanizm wykrywa powtarzające się błędy a całość składa do logów których nazwa to data wystąpienia błędu - jest to o tyle wygodne że otwierając log i widząc pliki od razu wiem co się stało i lecę od najstarszego.
Dodatkowo mam ręczny mechanizm który bada poprawność wszystkich bibliotek w systemie właśnie pod kątem błędów składni (PHP ma funkcję token_get_all która bardzo pomaga). Uruchamiam go zawsze jak dorzucam np nowy moduł.
Dodatkowo niektóre klasy jak np obsługa danych (nie tylko bazy danych) ma nazwijmy to tryb bezpieczny. Tzn zawsze spodziewam się na wyjściu albo obiektu albo tablicy obiektów albo czegoś w ten deseń. Tryb bezpieczny zapewnia mi to że jeżeli zapytanie się wysypie z jakiegoś powodu to zapytanie, parametry oraz sam błąd zostaną zalogowane jak każdy inny błąd a metoda zwróci pustą tablicę co aplikacja traktuje jako "zadziałało poprawnie ale nie ma rekordów".

Jeżeli trzymamy się wytycznych to nie powinno się to źle skończyć. Przykład logowania gdzie pobieram dane użytkownika i uprawnienia. Jeżeli pobieranie użytkownika się nie powiedzie to rzecz jasna nie zaloguje się. Jeżeli to się uda a coś siądzie przy pobieraniu uprawnień to zwyczajnie... na daną sesję użytkownik nie będzie miał uprawnień przy czym fakt tego problemu zostanie zapisany i przy odświeżeniu aplikacja ponownie spróbuje je pobrać.

Ot taki przykład.

Temat: kontrola błędów sql

Czyli, reasumując, są takie WYJĄTKOWE sytuacje, gdzie komunikatu o błędzie można nie wyświetlać. Natomiast twierdzenie, że WIĘKSZOŚĆ można pominąć od razu budzi mój sprzeciw. W swojej karierze zawodowej spotkałem już parę razy sytuację, gdy wypełniam jakiś sążnisty formularz, klikam "Zapisz" a dane idą w kosmos bez żadnej informacji o tym fakcie. W przypadku jakichś tam prywatnych stronek może i nie ma to znaczenia ale w aplikacjach biznesowych, to jest wręcz niedopuszczalne. Wyobraźcie sobie jakiś formularz zgłoszeniowy, gdzie termin zgłoszeń mija dziś o północy a potem wyobraźcie sobie, że system wysypał się podczas wysyłki zgłoszenia bez poinformowania użytkownika. Całkiem niedawno miałem "w ręku" taką radosną twórczość.

Temat: kontrola błędów sql

Obsługa błędu a informowanie użytkownika to dwie różne rzeczy.

Temat: kontrola błędów sql

Andrzej Prażmo:
Czyli, reasumując, są takie WYJĄTKOWE sytuacje, gdzie komunikatu o błędzie można nie wyświetlać. Natomiast twierdzenie, że WIĘKSZOŚĆ można pominąć od razu budzi mój sprzeciw. W swojej karierze zawodowej spotkałem już parę razy sytuację, gdy wypełniam jakiś sążnisty formularz, klikam "Zapisz" a dane idą w kosmos bez żadnej informacji o tym fakcie. W przypadku jakichś tam prywatnych stronek może i nie ma to znaczenia ale w aplikacjach biznesowych, to jest wręcz niedopuszczalne. Wyobraźcie sobie jakiś formularz zgłoszeniowy, gdzie termin zgłoszeń mija dziś o północy a potem wyobraźcie sobie, że system wysypał się podczas wysyłki zgłoszenia bez poinformowania użytkownika. Całkiem niedawno miałem "w ręku" taką radosną twórczość.

Po zdjęciu widzę że starszy z Ciebie człowiek i NADAL mam głębokie przekonanie że rozumiesz tekst pisany. Także proszę Cie byś jeszcze raz przeczytał moje wypowiedzi wyżej i spróbował je zrozumieć.

Biorąc pod uwagę że @Michał chyba zrozumiał, podobnie jak @Krzysztof (który dodatkowo rzucił bardzo przydatną funkcją), stawiam na to że jednak nie opisałem tego o czym mówiłem niejasno.

W razie problemów spróbuję krok po kroku jaśniej wytłumaczyć z przykładami i obrazkami. Jak tylko z najdę troszkę czasu. Jeszcze raz dam słowa klucze - "dane wyświetlane" w celu naprowadzenia na właściwe tory...

Pozdrawiam

Temat: kontrola błędów sql

"Nie licząc sytuacji newralgicznych jak np pobranie uprawnień albo danych użytkownika, większość tego co wyświetlamy na ekranie jest kompletnie ZBĘDNA. Co za tym idzie - jeżeli baza zwróciła błąd, ten fakt powinien być gdzieś zalogowany (nietrudno to wykryć w końcu a jeszcze łatwiej zrzucić dane do pliku albo psiakoś inaczej ) a aplikacja powinna działać dalej bez wiedzy użytkownika."

Powyższy cytat jest dla mnie dość jasny: owszem, zapisujmy sobie gdzieś błędy ale użytkownik lepiej, żeby o nich nie wiedział. Ja się z takim stylem programowania nie zgadzam i tyle. Głównie dlatego, że uważam użytkownika za bardzo istotny "składnik" aplikacji, który daje mi więcej informacji na temat działania programu niż stado testerów.

Temat: kontrola błędów sql

Czyli informujesz użytkownika o tym że nie udało się zapisać przykładowego formularza z pełnym zestawem informacji dlaczego to nastąpiło?

Wg mnie bez sensu - po co użytkownikowi informacja że nastąpił timeout połączenia, przekroczono ilość możliwych połączeń do DB czy coś w tym stylu? Co on zrobi z tą informacją?
Dla użytkownika istotna jest informacja że zapis się nie powiódł i problem nie wystąpił z jego winy (czyli dane wpisał poprawnie).

Wystarczy że go przeprosisz i poprosisz by spróbował za chwilę.

Temat: kontrola błędów sql

Andrzej Prażmo:
"Nie licząc sytuacji newralgicznych jak np pobranie uprawnień albo danych użytkownika, większość tego co wyświetlamy na ekranie jest kompletnie ZBĘDNA. Co za tym idzie - jeżeli baza zwróciła błąd, ten fakt powinien być gdzieś zalogowany (nietrudno to wykryć w końcu a jeszcze łatwiej zrzucić dane do pliku albo psiakoś inaczej ) a aplikacja powinna działać dalej bez wiedzy użytkownika."

Powyższy cytat jest dla mnie dość jasny: owszem, zapisujmy sobie gdzieś błędy ale użytkownik lepiej, żeby o nich nie wiedział. Ja się z takim stylem programowania nie zgadzam i tyle. Głównie dlatego, że uważam użytkownika za bardzo istotny "składnik" aplikacji, który daje mi więcej informacji na temat działania programu niż stado testerów.

Na przykładzie zdjęcia które wstawiłem wcześniej. Tak dla jasności.





Jest tam parę czerwonych obszarów. Weźmy "polecane galerie". Tam gdzieś jest zapytanie sql, jakiś skrypt czy cuś co pobierze kilka popularnych albo wybranych przez gry-online galerii.

Powiedzmy że jest piątek wieczór a ktoś się upiera żeby zaktualizować ten obszar o nowy algorytm który np wyeliminuje konieczność przygotowania listy. Więc ktoś pisze, pisze, pisze i puszcza aktualizacje. "Jemu działa" więc idzie do domu nie wiedząc że z jakiegoś powodu każdemu innemu użytkownikowi wyrzuca błąd zapytania. Hipotetyczna sytuacja.

Pańskie podejście - gdzieś pojawia się błąd w związku z tym blokiem i pojawia się cały weekend. Albo w miejscu występowania bloku, albo w innym miejscu witryny albo coś...

Moje podejście - kontrola błędów wyłapuje ów błąd a mechanizm składnia strony pomija blok z błędem. Ewentualnie prostsze rozwiązanie - lista się nie wyświetla.

Pańskie podejście - użytkownicy widzą informacje o błędzie i zyskują wiedzę na temat naszej aplikacji która może być wykorzystana w dobry lub zły sposób. Znam multum takich przypadków gdzie wyrzucony błąd serwował nam lokalizację pliku, backtrace zdarzenia czy nawet zapytanie SQL które zdradza strukturę tabeli co może np później pomóc w SQL Injection. Spotkałem się nawet z sytuacjami gdzie wywalenie się bazy danych skutkowało z pokazaniem fragmentu odpowiedzialnego za połączenie zawierający login i hasło do bazy...
DO WYBORU, DO KOLORU

Moje podejście - użytkownik nawet nie zauważył że coś się stało. Na mojej skrzynce email jest informacja o wystąpieniu błędu którą to wysłała sama aplikacja. W logach aplikacji mam
~ czas zdarzenia
~ miejsce zdarzenia
~ komunikat zdarzenia
~ użytkownika któremu to się stało
~ backtrace
~ wykonane zapytania
~ zawartość superglobals z początku skryptu i miejsca wystąpienia błędu

To niemal wszystko co jest mi potrzebne do poprawki błędu. A jeżeli nie dojdę to aa pomocą JEDNEGO GŁUPIEGO SKYPTU jaki posiada mój panel administracyjny mogę sobie wybrać błąd z raportu i wywołać stronę mającą dokładnie ten sam stan (skrypt przywraca sesję początkową z programu, wywołuje URL wraz z ewentualnymi danymi przesłanego formularza itp) i dokładnie prześledzić co się stało.

Pytanie: w jaki sposób może mi pomóc użytkownik ?? Aplikacja loguje niemal wszystkie anomalie jakie się wydarzą a z funkcją która podał mi Krzysztof może logować wszystkie. Użytkownik tutaj się przydaje wtedy kiedy to skrypt aplikacji jest nieprawidłowy i daje błędne wyniki ale tutaj błędy się NIE POJAWIĄ i tutaj użytkownik anomalię i tak zauważy.

Pytanie 2: Czy Pan w swoim świętym przekonaniu o tym że robię źle nie myli przypadkiem INFORMOWANIA użytkownika że coś się np nie zapisało z RADZENIEM SOBIE Z BŁĘDAMI i kontynuowaniem aplikacji jeżeli to możliwe ?

Ja nie widzę problemu w tym że ktoś walną literówkę w SELECT. Użytkownik nie dostaje informacji jakie ów SELECT miał dla niego pobrać i jeżeli nie jest to potrzebne (jak te polecane galerie) to nawet nie dowie się że coś takiego MIAŁ dostać a ja dostanę w tym samym momencie informacje że SELECT ma literówkę, poprawię go i wszystko wróci do normy. Pytania ?

I tu dochodzimy do różnicy między gry-online.pl a np intranetem firmy. Na gry-online.pl blok który wygenerował błąd wyrzucił by wyjątek dla kontrolera który zajmuje się generowaniem strony. Kontroler wyłapał by błąd i nie dołączył by owego obszaru do strony. Więc blok by się nie pojawił.
W Intranecie ów blok by się pojawił ale w miejscu listy była by notka że z powodu awarii lub błędu informacja nie wyświetla się bo intranety na ogół nie zawierają zbędnych informacji w widokach.

Trzeba być elastycznym a nie iść w zaparte. Dariusz Półtorak edytował(a) ten post dnia 27.05.12 o godzinie 11:19

Temat: kontrola błędów sql

różnica pomiędzy waszymi opiniami pewnie wynika z tego że Andrzej głównie zajmuje się aplikacjami dla windows.

Temat: kontrola błędów sql

Krzysztof D.:
różnica pomiędzy waszymi opiniami pewnie wynika z tego że Andrzej głównie zajmuje się aplikacjami dla windows.

Nie rozumiem gdzie jest różnica?Michał Wachowski edytował(a) ten post dnia 27.05.12 o godzinie 11:47

Temat: kontrola błędów sql

większość aplikacji windows nie wysyła maila z błędem, a zapisanie błędu do pliku, nie rozwiązuje problemu. w rzeczywistości użytkownik ma w ten sposób dostęp do jeszcze większej ilości danych (zakładając że zalogujesz wszystko co Ci jest potrzebne do wyeliminowania błędu).
tak więc pojawia się pytanie, co z tego że szczegółowego błędu nie wyświetlisz, skoro i tak użytkownik ma dostęp do pełnego loga ?
spójrz jak wyglądają błędy w windows to będziesz wiedział o czym mówię. nie są to proste komunikaty typu "ooo, coś się zepsuło, spróbuj ponownie".

ale wróćmy może do PHP. I tu akurat mam podobne podejście do Dariusza. wręcz w mailu wysyłanym do mnie mam te same dane.

W ramach tematu interesowało mnie jak obsługujecie błędy występujące w klasach. np. w klasie obsługującej bazę danych. sprzężenie jej z zewnętrznie zdefiniowaną własną funkcją obsługi błędu (tudzież klasą) nie jest idealnym rozwiązaniem, ale pewnie często stosowanym.

obecnie mam klasyczne stare rozwiązanie gdzie funkcje klas generują false w przypadku błędu. a obsługa błędu jest po stronie wywołującej ową funkcję.Krzysztof D. edytował(a) ten post dnia 27.05.12 o godzinie 12:13