LINUX SOFTWARE

Chybovat je lidské. A taky to dobře jde počítačům. Podívejme se, jak to zvládá PHP a jak ho to odnaučit.

23.7.2004 15:00 | Petr Zajíc | přečteno 46899×

Pozn.: Chybovat je opravdu lidské. Minule jsem slíbil v závěru článku, že se budeme příště zabývat prací se soubory. Takže, moc se omlouvám, bude to až v dalším díle. Úplně mi vypadl tento díl seriálu z hlavy ;-)

Můrou každého programátora jsou chyby v jeho programech. Nemyslím si, že by se daly napsat programy bez chyb. Ale správným přístupem k problému se nám může podařit chyby minimalizovat. Podívejme se, jak na to můžeme jít v PHP.

V programech se běžně vyskytuje pět druhů chyb. To se týká i PHP. Zkusme si je rozebrat jeden typ za druhým, ukázat si příklady a dát si nějaké návody, jak se takovým chybám buďto vyhnout, nebo je alespoň utajit před uživateli.

Syntaktické chyby

Syntaktické chyby jsou nejjednodušší na vytvoření, ale taky na odhalení. Syntaktická chyba je všechno, co způsobí neplatný kód PHP. Tak například můžete zapomenout středník nebo uvozovky. Následující kód je špatně:

<?

$uzivatel="Petr";

$server="Linuxsoft";

echo "Uživatel $uzivatel je vítán na
serveru $server!<BR>"

echo "Máte
novou poštu";

?>

a při pokusu jej spustit dostaneme hlášení od PHP ve smyslu:

Parse error: parse error, unexpected T_ECHO, expecting ',' or ';' in D:\Pokus\source.php on line 5

PHP je na toto poměrně hodný jazyk - řekne nám, na jakém řádku chyba je a co se mu nezdá. Mimochodem o toho čísla řádku si může trochu vymýšlet - sami přece vidíte, že ten zapomenutý středník je na řádku 4. Ale PHP to zjistí až v momentě, kdy narazí na příkaz echo, který je o řádek níž. Syntaktické chyby se odnaučíte častým používáním PHP. Časem to pro Vás nebude problém.

Sémantické chyby

To už jsou horší chyby. Sémantická chyba vznikne u kódu, který projde parsováním, ale nepůjde spustit. Tak mějme například následující kód:

<?

$retezec="Dneska
je ale zima...";

explode ($retezec);

?>

Jelikož funkce explode vyžaduje ne jeden ale dva parametry, zaprotestuje pochopitelně PHP způsobem:

Warning: Wrong parameter count for explode() in D:\Pokus\source.php on line 3

Rovněž tyto chyby se dají poměrně solidně najít a opravit. Bylo by ideální, kdybyste si před uvedením aplikace do provozu mohli být jisti, že jste testovali každý kus kódu (třeba každou větev v podmínce), protože pak byste se sémantických chyb víceméně nemuseli bát. K tomu v reálných aplikacích slouží testovací plány, které se snaží navrhnout sadu testovacích rutin tak, aby se prošel celý kód. To je docela věda a určitě to je mimo náplň našeho seriálu.

Logické chyby

Takže kód běží, aplikace nepadá - může nás ještě vůbec něco překvapit? Ano, jsou to logické chyby. PHP je poměrně benevolentní jazyk - což taky znamená, že Vám umožní kdejakou věc, kterou by Vám přísnější jazyky zakázaly. Tak například byste mohli podlehnout pokušení použít pro sloučení řetězců plusítko (+) namísto tečky (.). Následující kód je správný syntakticky i sémanticky - a přesto je výsledek logicky špatný:

<?

$jmeno="Johny";

$prijmeni="Wolker";

$cele = $jmeno+" "+$prijmeni;

echo $cele;

?>

Tady jsme se pokusili pracovat s řetězci jako s čísly. Na což PHP zareagovalo přetypováním a převedlo vše na čísla. Výsledkem je nula. Logické chyby bývá obtížné vystopovat. Projevují se totiž pouze někdy a v systému jsou pak schopny nadělat pěknou paseku. Kdybyste například v uvedeném příkladu doufali, že proměnnou $cele časem použijete jako logickou proměnnou, je neštěstí na světě. Obecná rada je: Testujte jednotlivé kusy kódu předtím, než je sestavíte dohromady. Čím větší celek, tím hůř se na chyby přichází.

Chyby v samotném PHP

Tím, že PHP používají milióny lidí, se už mnoho chyb vychytalo. Přesto Vás PHP může nepříjemně překvapit samo o sobě. Následující kód ilustruje, že PHP neumí v určitých případech počítat kalendářní dny, neboť následující pondělí zcela určitě není v neděli:

<?

$jmeno="Johny";

$prijmeni="Wolker";

$cele = $jmeno+" "+$prijmeni;

echo $cele;

?><?php

  $tStamp = mktime (0, 0, 0, 10, 27, 2004);

  echo "tStamp=". date("l d.m.Y", $tStamp). "<BR>\n";



  $strtotime_timestamp = strtotime ("next Monday", $tStamp);

  echo "result=". date("l d.m.Y", $strtotime_timestamp)."<BR>\n";

?>

Pokud narazíte na chybu v PHP, je rozumné ji popsat autorům, kteří se ji pokusí odstranit. K tomu slouží webové rozhraní. Dokud ale chyba nebude opravena, nemůžete toho dělat moc; já se vždy pokusím kód přepsat, většinou to funguje.

Chyby mimo PHP

Chyba může být i mimo prostředí PHP (ale vysvětlete to uživatelům...). Vymyslet konkrétní příklad mě zrovna nenapadá, ale může se jednat o chyby způsobené neexistujícími soubory, nepřístupnými databázemi, chybějícími skripty začlenění, nedostatečným místem na disku, špatnými odpověďmi http serveru a podobně. Obecná zásada je: "nikomu nevěřit". Psát programy tak, abychom přinejmenším věděli, kde a jaká chyba nastala. S tím souvisí následující otázka:

Jaké chyby PHP hlásí?

PHP hlásí 4 typy chyb, které ale přesně nezapadají do skupin chyb popsaných výše. Je to takhle:

Úroveň chyby	Význam
Chyby čtení (Parse)	To jsou de facto syntaktické chyby
Závažné chyby (Fatal)	To jsou buď sémantické chyby, nebo chyby prostředí, z nichž se PHP nedokáže zotavit (například nedefinovaná funkce).
Varování (Warnings)	To jsou chyby podobné závažným, ale zároveň si PHP myslí, že může pokračovat dál. Většinou to ale stejně není pravda.
Upozornění (Notices)	Bývá většinou v reále vypnuto. Méně podstatné chyby, například neinicializované proměnné.

Co s chybami?

Programátor by se měl nad chybami zamýšlet trochu jako uživatel. Uživatelé chyby nevidí rádi. Nicméně - někdy se dá použít metoda "co oko nevidí, srdce nebolí". Mějme například nějakou funkci pro zvýšení hodnoty počitadla, která selže. Musí se to uživatel dozvědět? Vlastně vůbec ne. Pokud požijeme před voláním funkce operátor @ (zavináč) , chybové hlášení v PHP bude potlačeno. Takže, můžete napsat něco ve smyslu:

<?

@ZvysHodnotuPocitadla();

?>

Pozor, nefunguje to u příkazů, jen u funkcí. To, jaké chyby bude PHP hlásit se dá omezit pomocí funkce error_reporting. To, že se budou chyby zapisovat pro případné další zkoumání, zajišťuje funkce error_log. Systém ovšem musí být nastaven pro její použití.

Samozřejmě, že metodu "strkání hlavy do písku" nelze použít vždy. Pakliže nastane chyba při připojování se k databázi, a bude se jednat o elektronický obchod, budeme asi muset s tím něco dělat, neb bez databáze zákazník nenakoupí. Takové chyby poznáme. Většina funkcí pro práci s databázemi totiž vrací nějakou hodnotu, když selžou. Tuto hodnotu můžeme testovat. Pro ilustraci může sloužit následující kus kódu:

<?

  if (ZkusSePripojitKDatabazi)

  {

    //jedeme dál

  }

  else

  {

    //chyba.
Informujeme nebohého uživatele

    echo "Váš požadavek nyní nelze vyřídit.";

  }

?>

Kód je jasný. Naše skvělá funkce ZkusSePripojitKDatabazi může vrátit TRUE nebo FALSE. Pokud to nedopadlo správně, dostaneme se do druhé větve podmínky. Je dobré se uživateli nějak diplomaticky omluvit. Tady Vám může pomoci několik programátorsko - psychologických pravidel:

Nepoužívejte slovo chyba, když dojde k chybě. Přiznali byste, že program je špatně napsaný. Existují výjimky, nestandardní situace, ale nikdy chyby.
Ze stejného důvodu se tam nesmí objevit ani slovo error.
Snažte se být slušní. Uživatel za chybu nikdy nemůže. I když ji způsobil (třeba špatným vstupem).
Snažte se být nenápadní. Vytvořte si funkci, která chybu vysvětlí pomocí stejných prvků designu, jako kdyby se operace povedla. Mám tím třeba na mysli, že nutně nemusíte psát chyby červeně na prázdnou stránku, když byste dost dobře mohli použít pozadí, které tam máte normálně.
Snažte se vysvětlit, co může uživatel udělat (přihlásit se za 5 minut, zavolat na technickou podporu, vyskočit z okna a podobně)
Nepište tam takové věci jako čísla řádku, chybovou hlášku PHP a podobně. Uživatele to nezajímá, on má chybu.

Příště se budeme věnovat už opravdu práci se soubory.