DevProTalk - PHP5 Exceptions

DevProTalk

DevProTalk (http://www.devprotalk.com/index.php)

- PHP (http://www.devprotalk.com/forumdisplay.php?f=9)

- - PHP5 Exceptions (http://www.devprotalk.com/showthread.php?t=640)

bluesman

09. 02. 2006. 13:38

PHP5 Exceptions

Kao što verovatno svi znate, PHP5 ima mogućnost postavljanja Exceptions kao većina ozbiljnih programskih jezika. Pošto prepravljam neke klase da budu PHP5 only, interesuje me koja je, osim semantičke, prednost upotrebe Exceptions u odnosu na neko klasično "prikupljanje grešaka" u kodu.

Recimo, imamo najgori slučaj i lošu programersku praksu tipa:

PHP kôd:


		
			
$date = getSomeData ();
if (empty($data))
    die ("Data empty");
...

to neću ni da komentarišem.

Onda imam slučaj koji ja koristim (u PHP < 5)

PHP kôd:


		
			
$data = getSomeData ();
if (empty($data))
    $ErrorClass->addError ("Data empty, line: ".__LINE__, ERR_NON_CRITICAL);
...

if ($ErrorClass->hasErrors())
{
    $ErrorClass->displayErrors();
}

ili nešto slično... znači prikupljaju se greške i jednostavno prikažu negde (ili samo u debug) ali izvršenje scripta se nastavlja.

Koja je prednost (performanse, memorija... whatever) ako ja prepravim moj sistem da koristi exceptions, na primer ovako:

PHP kôd:


		
			
try {
    $data = getSomeData ();
    if (empty($data))
       throw new Exception ("Data empty, line: ".__LINE__, ERR_NON_CRITICAL);
...
} catch (Expception $e) {
    echo "Greška ".$e->getMessage();
}

...

Znači, ovo su samo primeri bez veze, čisto me interesuje šta se tačno dobija po pitanju performansi, resursa ili nečeg drugog kada se upotrebljavaju Exceptions. Ja ne vidim neki značajan boljitak u kodu osim u preglednosti.

Ilija Studen

09. 02. 2006. 18:19

Hvata greške na jednom mestu i ne brineš gde će se desiti (koliko "duboko"). Ovo je izuzetno bitno kod kompleksnih aplikacija. Primer:

PHP kôd:


		
			
$user = new User();
$user->setUsername('root');
try {
  $user->save();
} catch(Exception $e) {
  die('Error! ' . $e->getMessage());
}

Do greške može doći jer objekat ne prolazi validaciju (root je prekatak user ili korisnik root već postoji) ili zbog greške u izvršavanju upita. Bilo kako bilo, ti je hvataš na jednom mestu. Dalje, jednostavno možeš obraditi više tipova greške:

PHP kôd:


		
			
try {
  $user->save();
} catch(ValidationException $e) {
  die('Validation error:<br />' . implode('<br />', $e->getErrors()));
} catch(QueryException $e) {
  die('Query error! ' . $e->getSQL());
}

Pošto su izuzeci objekti možeš da čuvaš mnogo podataka o samoj grešci.

Nije da se ne može postići klasičnim metodama, ali to je već hakeraj i podrazumeva puno prljavog petljanja koje samo čini kod složenijim i podložnijim greškama. Izuzeci čine život lakšim :)

bluesman

09. 02. 2006. 18:42

Hvala Ilija na odgovoru, moje pitanje je bilo vezano za nešto drugo:

Citat:

Znači, ovo su samo primeri bez veze, čisto me interesuje šta se tačno dobija po pitanju performansi, resursa ili nečeg drugog kada se upotrebljavaju Exceptions.

Pa sam rekao:

Citat:

Ja ne vidim neki značajan boljitak u kodu osim u preglednosti.

A ti si odgovorio:

Citat:

Nije da se ne može postići klasičnim metodama, ali to je već hakeraj i podrazumeva puno prljavog petljanja koje samo čini kod složenijim i podložnijim greškama. Izuzeci čine život lakšim

Moze i "klasičnim" metodama da se kreira objekat za svaku grešku, mene znači interesuje koliko exceptions utiču na same performanse ili resurse. Da li uopšte postoji takva neka analiza. Da li uopšte postoji boljitak po tom pitanju ili je samo "lepši kod"? Kako uopšte PHP barata sa Exceptions?

Znači šta se desi kada se raise-uje (ili ovde "throw") exception a nema catch? I koliko su važne exceptions uopšte za tako kratak run-time kao što je run-time PHP scripta?

Ilija Studen

09. 02. 2006. 20:34

Sorry, bio sam umoran pa sam temu skontao u kontekstu "Šta će mi uopšte exception kad mogu xxx"

Što se performansi tiče da predstavljaju ozbiljan performance problem to bi bilo već negde naglašeno (u manualu, u korisničkim komentarima?) Objekat kao objekat, ne bi trebalo da unosi probleme. No, postoji jedan način da se to sazna :D Pojuriš skripticu u kojoj će proveravati koliko vremena treba da se exception "izvuče" i obradi pa to uporediš sa metodom koji si ranije koristio.

PS: Znam da znaš, ali nije od zgoreg da ponovim: premature optimization is the root of all evil. Napravi skriptu tako da je kvalitetno iskodirana pa onda juri uska grla. Nemoj odbaciti exceptione i neke druge OO stvari samo zato što ti se čini da mogu da predstavljaju performance problem ;)

Citat:

Originalno napisao Harry Fuecks

Looking for ways to optimize code should be a final stage of design.

bluesman

09. 02. 2006. 21:05

Nisam mislio da mi ne treba exception, nisam cak ni pomislio da ih odbacim, niti mislim da mogu da budu performance problem... na kraju ne mogu biti lošije od "dosadašnjih rešenja", naprotiv, pitam se da li su ne bilo koji način exceptions optimizovane da poboljšavaju performanse ili se ipak na kraju svodi na to da je, što se resursa tiče, potpuno sve jedno.

Ilija Studen

09. 02. 2006. 21:42

Ja ne vidim na koji bi način exceptioni doneli poboljšanje performansi pošto su oni dodatak na PHP4, ne izmena postojećeg sistema (PHP4 nije imao sistem za baratanje izuzecima). Ne znam stvarno sa čime bi mogao uporediti exceptione osim sa nekim custom rešenjem za PHP4...

bluesman

09. 02. 2006. 21:53

To sam i pretpostavljao...

Možda ću i odustati od prepravljanja php4 koda u php5. :)

Vreme je GMT +2. Trenutno vreme je 12:24.

Powered by vBulletin® Verzija 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © DevProTalk. All Rights Reserved.

Mišljenja, saveti, izjave, ponude ili druge informacije ili sadržaji nastali na Sajtu su vlasništvo onoga ko ih je kreirao, a ne DevProTalk.com, tako da ne morate da se oslanjate na njih.
Autori poruka su jedini odgovorni za ovakve sadržaje. DevProTalk.com ne garantuje tačnost, kompletnost ili upotrebnu vrednost informacija, stavova, saveta ili datih izjava. Ne postoje uslovi pod kojima bi mi bili odgovorni za štetu ili gubitak koji je posledica bilo čijeg oslanjanja na nepouzdane informacije, ili bilo kakve informacije nastale kroz komunikaciju između registrovanih članova.
Web sajt može sadržavati linkove na druge web sajtove na Internetu ili neke druge sadržaje. Ne kontrolišemo niti podržavamo te druge web sajtove, niti smo pregledali bilo kakve sadržaje na takvim sajtovima. Mi nećemo biti odgovorni za legalnost, tačnost ili prikladnost bilo kog sadržaja, oglasa, proizvoda, usluga ili informacije lociranim na ili distribuiranih kroz druge web sajtove, niti za bilo kakvu štetu nastalu kao posledica takvih informacija. DevProTalk.com drži i čuva druga prava vlasništva na web sajtu. Web sajt sadrže materijale zaštićene copyright-om, zaštitne znakove i druge informacije o pravu vlasništva ili softver. Članovi mogu poslatu informacije zaštićene pravima vlasništva njihovih nosilaca i ona ostaju zaštićena bez obzira da li su oni koji prenose te informacije to naveli ili ne. Osim informacija koje su u javnom vlasništvu ili za koje dobijete dozvolu, nemate pravo da kopirate, modifikujete ili na bilo koji način menjate, objavljujete, prenosite, distribuirate, izvršavate, prikazujete ili prodajte bilo koju informaciju zaštićenu pravima vlasništva. Slanjem informacija ili sadržaja na bilo koji deo DevProTalk.com, Vi automatski dozvoljavate i predstavljate garanciju da imate pravo da dozvolite DevProTalk.com ili članovima DevProTalk.com bespovratnu, kontinualnu, neograničenu, globalnu dozvolu da koriste, kopiraju, izvršavaju, prikazuju i distribuiraju takve informacije i sadržaje i da iz takvih sadžaja koriste bilo koji deo u bilo koje svrhe, kao i pravo i dozvolu da koriste gore navedene sadržaje. Svi zaštitni znakovi (trademarks), logotipi, oznake usluga, firme ili imena proizvoda koji se pominju na ovom web sajtu su vlasništvo kojim raspolažu njihovi vlasnici.