Witajcie, poniżej wklejam to co stworzyłem sobie od obsługi błędów i komunikatów (jeszcze nie skończone). Pojawił się spory problem z MySql, chodzi mi o błąd połączenia, proste pytanie jak go złapać ?

[PHP] pobierz, plaintext 
$errors = array(
  'error' => array(),
  'warning' => array(),
  'notice' => array());
 
class Error extends Exception
{
  protected $level = 'error';
  function getLevel()
  {
    return $this->level;
  }
}
 
class Warning extends Error
{
  protected $level = 'warning';
}
 
class Notice extends Error
{
  protected $level = 'notice';
}
 
function msg($e)
{
  global $errors;
  $errors[$e->getLevel()][] = (String)$e;
  if($e->getLevel() == 'error') { 
    $tpl = New Template();
    $tpl -> assign('e', $e->getMessage());
    $tpl -> display('przyklad_bledy.php');
    die();
  } elseif($e->getLevel() == 'notice') {
   // echo $e->getLine().' -> '.$e->getMessage();
  } 
}
 
function exception_handler($e)
{
  msg($e);
}
 
function error_handler($no, $str, $file, $line)
{
  if(production_mode === true) {
    $msgContent = 'Napotkano błąd aplikacji, numer błędu: '.$no;
  } else {
    $msgContent = $no.' '.$str.' @ '.$file.' # '.$line;
  }
 
  msg(new Error($msgContent));
}
 
set_exception_handler('exception_handler');
set_error_handler('error_handler');
[PHP] pobierz, plaintext 

Wyłapujesz wyjątek za pomocą konstrukcji try {} catch(...) {} Jeśli mogę coś doradzić to nie trać czasu na wymyślanie koła na nowo i skorzystaj z chyba już standardowego i zalecanego rozwiązania pod tytułem PDO, które to rozwiązanie ma już wbudowaną obsługę wyjątków. Korzyść odniesiesz podwójną, bo poprawne używanie PDO zwiększa poziom bezpieczeństwa tworzonych rozwiązań webowych.

Jeśli uprzesz się na robienie po swojemu... Zobacz co zwraca mysql_connect i pozostałe funkcje mysql_* w przypadku błędów... Wykorzystaj to w swojej klasie

widzę że nie zrozumieliście problemu. Więc troszeczkę jaśniej

kolejność ładowania
- błędy
- sql

błąd się oczywiście wyświetla

[HTML] pobierz, plaintext 
"mysqli_connect() [function.mysqli-connect]: (28000/1045): Access denied for user 'ODBC'@'localhost' (using password: NO)"
[HTML] pobierz, plaintext 

zgodnie z definicją w msg(). Problem polega na tym by ten komunikat nadpisać, czyli musimy jakaś odróżnić w msg() błędy sql.

PDO - w sumie używałem go krótko i dawno temu, ale nie widzę żadnych powodów by go używać.

po co try{} skoro jest handler ?

Zapraszam na stronę dokumentacji http://www.php.net/manual/pl/mysqli.connect.php nie jest napisane, że rzuca wyjątkiem, zatem będzie po prostu drukować błąd na standardowe wyjście. W dokumentacji jest ten opisane jak to ominąć. Można sobie popatrzyć na dowolny ORM i zobaczyć, że w mysqli zawsze obsługa błędu połączenia to @mysqli_connect i $mysqli->connect_error.

Ogólnie popieram darko - nie ma sensu wymyślać koła na nowo. A używanie try{}catch jest po prostu bardziej estetyczne i w coraz szerszych kręgach profesjonalne. W PHP odchodzi się już od myślenia funkcyjnego mimo, że PHP wciąż jest językiem paradygmatowym.

przeczytaj wszystko co napisałem i pomyśl czemu to nie zadziała. (...) Po za tym nie wiem czy zauważyłeś że błąd jest poprawnie załapany...

a czy ktoś je wymyśla ?

Pierwsze słyszę, no ale kłócił się nie będę, jak lubisz ciągle klepać to samo to sobie klep. Biorąc pod uwagę że jeszcze niedawno OOP w php prawie nie istniało a dziś mamy zaledwie marne naśladownictwo... to fakt odchodzi się.

Jeśli mogę to prosił bym o skupienie się na problemie.

twoje wypowiedzi:


i nadal nie wiadomo o co ci chodzi bo nie tyle wymyślasz kolo od nowa, ile utrudniasz sobie życie

no to wyjaśnij mi proszę w czym sobie życie utrudniam ? i co takiego robię co już jest zrobione ?

Łopatologicznie:
to co przedstawiłem skutecznie łapie błąd w taki sposób jaki sobie zdefiniujemy ($msgContent), jak pisałem wyżej chodzi o proste rozpoznanie błędu połączenia z serwerem, błędu wyboru / dostępności bazy.

łopatologicznie: strpos() na $str i sprawdzasz czy zawiera mysql_connect itd. pomóc może też debug_backtrace()

utrudniasz sobie życie, bo zajmujesz się grupowaniem błędów zamiast ich usuwaniem - masz problem z szufladkowaniem błędów na takim a nie innym poziomie i dopóki tego nie zrozumiesz (i troche pokory) uzyskane informacje nie pomogą ci w debugu w jakiej by nie były formie. Dobry debug i profiler jest w każdym FW, PDO samo ma niezłe możliwości.

debug_backtrace() - nic przydatnego nie zwraca podobnie jak getTrace()
strpos() - no można i milion innych, miałem nadzieje że jest na to jakiś ładny i fajny sposób

no tutaj to mnie troszkę poraziłeś. W ramach wyjaśnienia do debugowania i obsługi błędów używam zupełnie czego innego (co nie trafia finalnie na serwer), kto tutaj wmieszał PDO i po co ? nie wiem. To co stworzyłem fakt jest stare (to tylko odświeżenie), ale nigdy nie miało służyć do tego o czym tu piszecie, z błędami ma tylko tyle wspólnego że je łapie i albo wyświetli w naturalnej formie albo zdefiniowany tekst. I masz racje błędy są po to by je usuwać, tylko że jak Ci stock albo serwer zdechnie to raczej wypada w jakiś ładny sposób o tym poinformować. Więc odpowiadając na Twój zarzut, nie szufladkuje błędów i nie mam z tym problemów (ale owszem wrzucam je do jednego wora > wszystkie).

Odnośnie PDO, osobiście do niego nic nie mam ale go nie używam bo nie jest mi potrzebne do szczęścia, czy podnosi poziom bezpieczeństwa ? mity i legendy. Dla mnie jego największą zaletą jest mobilność i współpraca z chyba każdym popularnym silnikiem bazodanowym. Z resztą jak pisano miał zostać w php6 podobnie jak mysqli (które też jest obiektowe i całkiem ciekawe).

odnośnie framework'ów, firmy wymagają przeważnie Zenda dlatego tylko jego jestem zwolennikiem, jednak uważam że używanie tak rozbudowanych narzędzi to prostych stron jest trochę przekombinowane.

Sumując, nie używam czegoś co nie jest mi potrzebne, czytać nie będę stosował FW/PDO bo inni tak mówią, bo jest fajne czy modnie jest używać. Nie jednokrotnie analizowałem na stałe używać Zenda, (PDO też)


Odnośnie tematu, to myślę że nie ma sensu dalej dywagować, działa jak ma, skoro się inaczej nie da to trudno. Thx za zainteresowanie.

Gdybyś tylko chwilę poświęcił na lekturę manuala doczytałbyś, o czym już zresztą wspomniał ~thek, co zwracają funkcje z rodziny mysql_* w przypadku błędu oraz jak za pomocą funkcji is_resource można sprawdzić czy w ogóle masz połączenie z bazą danych. Ty jednak wolisz sam tworzyć "mity i legendy", a my Cię nie mamy zamiaru powstrzymywać, skoro sam wiesz lepiej , co jest dla Ciebie dobre. Chciałbym tylko usłyszeć chociaż jeden sensowny argument przeciw używaniu PDO, poza tym nikt Ci niczego nie każe stosować, ostateczną decyzję podejmiesz sam.

czy gdzieś ktoś napisał że jest złe ? "darko" to może Ty spróbuj przekonać mnie do PDO (ale może na PW), skoro jest takie fajne to może ma coś o czym nie wiem.

is_resource, mysql_* i inne a zwłaszcza "Gdybyś tylko chwilę poświęcił na lekturę manuala doczytałbyś" - tutaj warto najpierw spojrzeć na siebie a potem krytykować innych, więc teraz ty zajrzyj do manula (albo bardziej podstaw php) i zobacz dlaczego to nie zadziała.

eh.. wiecie co ja nie jestem żaden guru, nie mam żadnej udokumentowanej wiedzy na temat php bo raczkuje w tym języku ale znam jego podstawy przynajmniej tak mi się wydaje. Jak stwierdził "kalmaceta" trochę pokory i by się przydało ale jak czytam co niektóre osoby wypisują to mnie po prostu na nią nie stać. Problem był z 1 błędem a wy z tego robicie nie wiadomo jakie grupowanie (z ciekawości co na to wskazuje ?), i wkładacie mi w usta nie wiadomo co. Gdzie ja napisałem że PDO jest złe ? to że czegoś nie chce używać bo nie widzę potrzeby to nie znaczy żę jest to nie wiadomo jakie badziewie, ludzie ile wy macie lat ? ! Kolejna sprawa, to nie jest podstawówka i wierzcie mi że nie raz przekopywałem manul w poszukiwaniu rozwiązań, wam za to nawet przez myśl nie przeszło że może ten prosty sposób nie zadziała.

W ramach wyjaśnienia do czego służy to co robię, oczywiście krytyka mile widziana (tylko sensowna). Potrzebowałem czegoś co w prosty i wygodny sposób umożliwi mi informowani o efekcie akcji użytkownika, czyli głupie proste wyświetlanie napisu "operacja się udała" "albo nie". Przy okazji stwierdziłem że ładnie będzie wyświetlić błędy (o ile się jakieś zdarzą) w konkretnym miejscu w jakiś cywilizowany sposób. Postanowiłem więc połączyć w to jeden worek. ot tyle.

po pierwsze przeczytaj swój pierwszy post - nie umiem złapać błędu, później piszesz że nie w tym rzecz, jak napisałem strpos to odpowiedziałeś że wiedziałeś, ale coś tam myślałeś..., rotfl

co do krytyki samego rozwiązania, na cholerę użytkownikowi wiedza że to błąd SQL, czystego php, linii, funkcji - jedyne co go może interesować to błędne dane przez niego wprowadzone, które powinny być odfiltrowane zanim przystąpisz do jakiejkolwiek akcji czyli error handler z tego powodu nic nie otrzyma do pracy.

tutaj niestety masz racje, cóż zobacz godzinę publikacji dlatego szybko w drugim poście się poprawiłem. Użyłem preg_match(), ale poprawiłem na strops'a bo tutaj też zadziała a jest na pewno szybszy. Myślałem po prostu że jest coś wbudowanego o czym nie wiem, tyle.

ad krytyki, tak masz rację i tak jest zrobione. Zobacz co jest w error_handler(), albo wyświetli się błąd w tradycyjnej postaci, albo tylko informacja że jest błąd i nic więcej. I tylko tyle otrzyma zwykły user, chciałem dodać tylko inny monit dla problemów z sqlem. Odnośnie filtrowania danych itd, tym już zajmuje się model (generuje listy, formularze, przeprowadza walidacje) i informuje nas o efekcie rzucając lub wywołując msg(). Wydaje mi się to dość wygodne.