Muszę się Was poradzić, jakiej obsługi błędów używacie?

Ja używam: $db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); zaraz po zdefiniowaniu połączenia.
Czy jest jakiś lepszy sposób. Może z dokładniejszymi opisami błędów?


pozdro

Łapanie wyjątków, to chyba najlepszy z dostępnych sposobów obsługi błędów dostępnych w PHP. Nie musisz zawsze sprawdzać if(!...), tylko wrzucasz w blok try i łapiesz jak trzeba, bez zagnieżdżania setek struktur kontrolnych.


One są i tak wystarczająco wyczerpujące. ;] Poza tym, komunikaty błędów bazy są identyczne we wszystkich sterownikach, gdyż ich treść zwraca biblioteka kliencka, a nie akurat PDO. PDO jest tylko front-endem dla biblioteki DBMS (w przypadku MySQL - libmysql) i jeśli chciałbyś dokładniejszych opisów błędów - musiałbyś się nią zająć, a nie PDO.

edit@down pewnie pokazane palcem, co konkretnie napisać, aby było ok, albo generowanie nowego, poprawnego zapytania.

No ale pytanie: co tam można jeszcze dokładniej podawać?

http://pl.php.net/manual/en/pdo.constants.php

Masz wszystkie stałe pre definiowane.

no ok, ale jak to ma się do pytania? Chodzilo o komunikat bledu a nie jakies parametry PDO

I to jest myśl

w takim razie niech kolega filtruje i używa PDOException class http://pl.php.net/manual/en/class.pdoexception.php , btw tu chodzi o obsługę błędów?

no przeciez uzywa wlasnie wyjatkow. w pytaniu chodzilo czy jest cos lepszego. Odpowiedź juz padla...

No a moje pytanie :
bylo pytaniem retorycznym

dzięki za wszystkie odp

Trocha nieściśle się wyraziłem. Chodziło mi może nie tyle co o obsługę błędów w pełnym zakresie (z wyjątkami) właśnie o komunikaty o błędach. Na razie ważne dla mnie jest czy był jakiś błąd i jaki. No i: $db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); mi to zapewnia. Czy używając try-catch dostane coś więcej? erix pisał, że komunikaty błędów są takie same. Co więc dostaje z używania try? Jaki w nim bonus siedzi. Ale tak w praktyce, nie w teorii:)

pozdro

A wiesz w ogóle jak działają wyjątki?

Powiem, szczerze że próbowałem się przez nie przebić ale nie zajarzyłem o co w nich bangla :| :\
Crozin mógłbyś coś napisać o tym jakieś 2 albo 3 zdania? Tak w celu pouczenia mniej zaawansowanego kolegi?


pozdro

W innych bardziej spójnych pod tym względem językach wyjątek jest rzucany gdy aplikacja nie może działać poprawnie - np. baza nieosiągalna, błąd w zapytaniu SQL itd. PDO dokładnie w ten sposób wykorzystuje wyjątki. Jeżeli coś jest nie tak to rzucony jest wyjątek, który powinien zostać przechwycony, działanie kodu zakończone, a wyjątek gdzieś zapisany dla programisty (a userowi wyświetlony komunikat że coś się popsuło).

Nie do końca jarzę o co bangla z tymi wyjątkami.

Skrypt jest wykonywany i natrafia na błąd i przerywa wykonywanie. Np brak domknięcia nawiasu albo błąd w zapytaniu sql albo odwołanie się do czegoś co nie istnieje.
I teraz wyświetla mi się błąd na ekranie, że w którejś linijce coś sknociłem. I to mam dzięki konfiguracji błędów w php.ini i dzięki:
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

No to co jeszcze mogę osiągnąć? Co to jest ten wyjątek no za cholerę nie jarzę.

pozdro

pseudokod


No i sproboj to zapisac bez uzycia wyjatkow, tak zebys sprawdzal kazda operacje, a w przypadku niepowodzenia pokazal ekran bledu:

przesadzacie...
Pewnie mnie zlinczujecie ale...
ja nie używam wyjątków (znaczy sporadycznie używam). Nie używam ich też przy PDO. Nie lubię tego shitu gdy jest nadużywany.
Błąd wczytywania newsow? ok, newsy sie nie wyswietlają, do logow idzie mi wpis o bledzie zapytania, user nie widzi wpisów.
błąd zalogowania? ok, user widzi info ze blad, do logow idzie info ze blad, kur##@$ nie dostaje.

Może to kwesta przyzwyczajenia. ale ku#$#4 dostaje jak widze jak ktoś pisze ze jak sie nie uzywa wyjątków to mozna ku#$#@ dostac

No nie przesadzaj; nie lubisz, gdy się nadużywa if? Wyjątki, to też struktura kontrolna.


A ja dostaję k@#(*$&, gdy widuję coś takiego:

[PHP] pobierz, plaintext 
if(zapiszdane1()){
    if(zapiszdane2()){
        if(zapiszdane3()){
            if(zapiszdane4()){
                echo 'wszystko ok!';
            }else{
                die('blad');
            }
        }else{
            die('blad');
        }
    }else{
        die('blad');
    }
}else{
    die('blad');
}
[PHP] pobierz, plaintext 

Skoro można wszystko pięknie ładnie napisać w takiej postaci:

[PHP] pobierz, plaintext 
try{
    zapiszdane1();
    zapiszdane2();
    zapiszdane3();
    zapiszdane4();
}catch(Exception $ex){
    die('blad');
}
[PHP] pobierz, plaintext 

hehe ;] Zależy jak zrobisz obsługę błędów. Jak będzie działa to jest dobra i tyle. Gorzej jak rzuci się coś nieprzewidzianego, co nie podpadnie pod system logowania błędów.

kurcze.... to ze nie uzywam wyjątków nie znaczy ze piszę tak jak tu pokazałeś. Jak widze taki kod to też załamki dostaje.

Pod system logowania błędów wchodzi każdy błąd.

Nie to miałem na myśli. Po prostu takie skrajne sytuacje wymagają odpowiedniej kontroli. Czasem zachodzi potrzeba wykonywania paru operacji ciurkiem, takiej pseudo-transakcji po stronie skryptu i zamiast klepać kilka(naście?) ifów lepiej wszystko oprzeć o wyjątki.


Uwierz, często coś takiego widuję.

Ale to jest wina programisty a nie techniki. Owszem, wyjątki mogą zmniejszyć ryzyko takich kodów ale kiepski programista i na wyjątkach ci zrobi taką kaszane ze wymiękniesz.

Miałem sporą styczność z wyjątkami w javie. być może miałem pecha bo musiałem korzystać z libów napisanych poprostu "cudnie" i niesamowicie się zraziłem do wyjątków.

Nie mówię że wyjątki są be. Mówię jedynie by nie pisać:

bo to ma się dla skrajnych przypadków.

Ojej, moze przesadzilem z ku***ca

Ale wyjatki pozwalaja oddzielic normalny kod akcji (wewnatrz try{}) od czesci do obslugi bledow (catch{}).
Zamiast miec lasu ifow() po prostu wykonuje operacje, a bledy obsluguje "na dole".

[PHP] pobierz, plaintext 
    public function _update($id = null)
    {
        try
        {
            $product = Product::find($id);
            $data = $this->params->get('product');
            $data['discount_limit'] = $data->getFloat('discount_limit') / 100.0; // 13.2% => 0.132
 
            $oldProfile = $product->getProfile();
            $oldOptionGroupID = $product->option_group_id;
            $product->setAll($data);
            $this->tryToCreateProducer($product); // ! after setAll() to overwrite producer_id
            $product->save();
 
            // categories
            $oldIDs = (array)$data->get('category_id')->get('old')->getAll();
            $newIDs = (array)$data->get('category_id')->get('new')->getAll();
            $product->updateCategoryAssignment( $oldIDs, $newIDs );
 
            // profile
            $newProfile = $product->getProfile();
            $this->setUpProfile($product, $this->form('product_field'), $oldProfile, $newProfile);
 
            // options/variants
            $oldVariantsData = $this->params['variant']['old'];
            $newVariantsData = $this->params['variant']['new'];
            $newOptionGroupID = $product->option_group_id;
            $this->setUpVariants($product, $newVariantsData, $oldVariantsData, $newOptionGroupID, $oldOptionGroupID );
 
            // index..
            $this->refreshProductNiceURLs($product);
            $this->reindexProduct($product);
        }
        catch ( DAO_ValidationException $e)
        {
            // tu pokaze ponownie ekran edycji produktu jesli w ktorymkolwiek miejscu produkt zostal nieprawidlowo wypelniony
            // danymi przez usera, a to moze byc kilka poziomow glebiej w poziomie wywolan metod (IF-hell jesli by to robic bez wyjatkow
            // ktore same "wyskakuja" w gore stosu wywolania
            // no i nie moge tu logowac bledow
            $this->view->product = $product;
            $this->renderAction('edit.tpl', 'product/tpl_admin/product_popup.tpl');
        }
    }
[PHP] pobierz, plaintext 

Ale ja tego nie neguje a nawet się z tym zgadzam

No teraz inny kod:

[PHP] pobierz, plaintext 
   try
        {
            $product = Product::find($id);
 
           $oldProfile = $product->getProfile();
 
           $newProfile = $product->getProfile();
 
        }
        catch ( DAO_ValidationException $e)
        {
        }
[PHP] pobierz, plaintext 

No i super. Tylko w tym momencie nie wiesz co wywolalo wyjątek. Czy to find, czy to getProfile dla oldProfie czy tez moze dla newProfile.
Zeby sie dowiedziec to find czy tez getProfile musi rzucac innym wyjątkiem. Juz wiec raz ze musisz zdefiniowac te wyjątki, dwa ze zaczyna ci rosnąc blok catchow.
No i znowu jednak nie bedziesz wiedzial czy to bylo oldProfile czy newProfile. Trzeba dodac parę ifow. Ostateczne sprawdzanie zaczyna wiec rosnąć w kod. nie zmienia to jednak faktu, ze jest prawdą to co mowiles: sprawdzanie oddzielilismy od logiki.

[PHP] pobierz, plaintext 
  try
        {
            $product = Product::find($id);
 
           $oldProfile = $product->getProfile();
 
           $newProfile = $product->getProfile();
 
        }
        catch ( DAO_ValidationException $e)
        {
        }
        catch ( FindException $e)
        {
        }
        catch ( getProfile $e)
        {
if (oldprofile)...
if (newProfile)
        }
[PHP] pobierz, plaintext 

Oczywiscie moze nas nic nie obchodzic co wywołało wyjątek - grunt ze sie pojawił i jest źle. Co go wywołało to se kiedys w logach poszukamy.

http://pl2.php.net/manual/pl/language.exce...s.extending.php - final public function getTrace(); // an array of the backtrace() ;]

To tak ogólnie.


Zależy, jak plujesz + to, co zacytowałem.

Nie o to mi chodzilo. To ze w logowaniu bledow bedziesz wiedzial co go wywolalo to oczywista sprawa. Ale chyba nie bedziesz w catchu analizowal sciezki bledu...

No nie, ale zawsze pozostaje kwestia konstrukcji wyjątków - możesz przecież przeciążyć konstruktor i pluć własnym wyjątkiem - co dalej zrobisz - Twoja wola.