LINUXSOFT.cz Přeskoč levou lištu
Uživatel: Heslo:  
   CZUKPL

> PHP (28) - Chybovati je lidské

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 | Články autora | přečteno 41026×

Komerční sdělení: Pořádáme Kurzy PHP

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.

Verze pro tisk

pridej.cz

 

DISKUZE

Nejsou žádné diskuzní příspěvky u dané položky.



Příspívat do diskuze mohou pouze registrovaní uživatelé.
> Vyhledávání software
> Vyhledávání článků

8.5.2016 17:19 /Redakce Linuxsoft.cz
PR: Dne 26.5.2016 proběhne v Praze konference Cloud computing v praxi. Tématy bude např. nejnovější trendy v oblasti cloudu a cloudových řešení, cloudové služby, infrastruktura cloudu, efektivní využití cloudu, možné nástrahy cloudů a jak se jim vyhnout
Přidat komentář

21.4.2016 8:01 /František Kučera
Spolek OpenAlt zve na 127. distribuovaný sraz příznivců svobodného softwaru a otevřených technologií (hardware, 3D tisk, SDR, DIY, makers…), který se bude konat ve čtvrtek 28. dubna od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5).
Přidat komentář

2.3.2016 22:41 /Ondřej Čečák
Letošní ročník konference InstallFest již tento víkend!
Přidat komentář

14.2.2016 16:39 /Redakce Linuxsoft.cz
O víkendu 5. a 6. března 2016 proběhne na pražském Strahově 8. ročník tradiční konference InstallFest. Celkem za dva dny uvidíte ​30 přednášek​ a ​6 workshopů.
Přidat komentář

5.2.2016 17:38 /Petr Ježek
Utilitka z XFce "xfce4-power-manager" nejen umožňuje nastavení lhůty pro uspání či hybernaci, ale i zapínání a vypínání prezentačního módu pro nerušené sledování videí. Stačí ji nastavit v každém vybavenějším panelu a v jakémkoli nontiled WM/DE.
Přidat komentář

10.1.2016 11:32 /Pavel `Goldenfish' Kysilka
LinuxMarket změnil provozovatele. Nově jej provozuje Marek Pszczolka. Více info a detaily #1 a #2.
Přidat komentář

29.12.2015 11:38 /Ondřej Čečák
Ještě posledních pár dní můžete přidávat příspěvky nebo nápady na Install Fest 2016, který se bude konat 5. a 6. března 2016.
Přidat komentář

8.12.2015 11:36 /Petr Ježek
Logické se stává realitou. LibreOffice a Thunderbird se mají dle článku na Redditu stát protiváhou MS řešení (MS Office a Outlook).
Přidat komentář

   Více ...   Přidat zprávičku

> Poslední diskuze

10.6.2016 21:10 / pavel riha
FreeBSD 10.3 a virtualizace

8.6.2016 21:56 / Milan Gallas
Nevalidní prefix m

7.5.2016 14:58 / Teodor Komárek
Soubory

20.4.2016 0:07 / Jakub Cleing
Sázkový panel PHP FUSION

9.4.2016 9:43 / jiwopene@gmail.com
Re: problém s dpkg a nemožností instalovat

Více ...

ISSN 1801-3805 | Provozovatel: Pavel Kysilka, IČ: 72868490 (2003-2016) | mail at linuxsoft dot cz | Design: www.megadesign.cz | Textová verze