Nastal čas na kakao - Ladění - MujMAC.cz - Apple, Mac OS X, Apple iPod

21. prosince 2004, 00.00 | Ty nevíš táto to ti bylo k pláči, kos tuhle pral se s počítači a hledal chybu v programu... tedy, omlouvám se čtenářům i panu Halasovi; nechal jsem se unést nadpisem článku. Pravda ovšem je, že v minulém dílu našeho seriálu jsme si slíbili, že dříve, než se pustíme do přehledu služeb tříd objektové knihovny Foundation Kit, se blíž podíváme právě na ladění – tedy odhalování a opravy chyb.

Ty nevíš táto to ti bylo k pláči, kos tuhle pral se s počítači a hledal chybu v programu... tedy, omlouvám se čtenářům i panu Halasovi; nechal jsem se unést nadpisem článku. Pravda ovšem je, že v minulém dílu našeho seriálu jsme si slíbili, že dříve, než se pustíme do přehledu služeb tříd objektové knihovny Foundation Kit, se blíž podíváme právě na ladění – tedy odhalování a opravy chyb.

Chyby překladu

Pokud snad uděláme chybu, již může odhalit už samotný překladač – nejspíše půjde o nějaký překlep, zapomenutý středník nebo podobně – je to jednoduché. Xcode takové chyby automaticky zobrazí v okně (v záložce "Errors and Warnings"), a po klepnutí na kteroukoli z nich nám ji zobrazí v editoru.

To je jednoduché, prosté a samozřejmé; za zmínku snad stojí jen několik drobností:

• Xcode nepřekládá nutně zdrojové soubory v témže pořadí, v jakém jsou zobrazeny v okně. Při delším překladu se proto může někdy stát, že vidíme zároveň chyby a varování ze současného i z minulého překladu (protože na odpovídající zdrojový soubor ještě nedošlo) – to může někdy být trochu matoucí;
• Objective C, jako všechny jazyky, založené na jazyce C, dovoluje spoustu "prasáren", jež mohou být leckdy i nebezpečné; je proto vhodné důsledně kontrolovat i "warningy". Kupříkladu varování, jež je na minulém obrázku zvýrazněno, indikuje, že jsme zapomněli na znak '@' před řetězcovou konstantou, a kdybychom jej ignorovali, program by "spadl" (protože bychom se pokoušeli pracovat s textem jako kdyby to byl objekt);
• Povšimněte si také druhé chyby ("statically allocated instance..."). Právě tak překladač Objective C hlásí zvláště mezi javskými programátory oblíbenou chybku – zapomenutou hvězdičku v deklaraci proměnné, jež obsahuje objekt známé třídy (tedy v našem případě "NSXMLParser xml" místo správného "NSXMLParser *xml").

Běhové chyby, ladění a gdb

Daleko zajímavější než chyby při překladu je hledání a odstraňování chyb běhových. Knihovny Cocoa a jazyk Objective C jsou naštěstí navrženy tak šikovně, že při dodržení základní opatrnosti obvykle programy fungují správně hned na první pokus; pokud tomu tak ovšem není, můžeme se někdy docela zapotit.

Problém může být právě v tom, jak vysokou úroveň služeb Cocoa nabízí: v "obyčejném" vývojovém prostředí, jež "za nás" takřka nic neudělá, můžeme snadno vyjít od funkce main a krokovat celý běh programu. V Cocoa to samozřejmě není možné – vždyť naprostá většina služeb je skryta kdesi na standardních knihovnách, a my jsme si je vyžádali jen nepřímo: kde hledat kód, který zajistí třeba korektní vazbu mezi obsahem textového pole a uživatelskými předvolbami, když jsme toho dosáhli bez jediného programového řádku, výhradně prostřednictvím "bindings"?

Každopádně, nenechte se vystrašit – tohle za normálních okolností problém nebývá, služby Cocoa vyšší úrovně "just work". Debugger potřebujeme většinou jen na odhalení případných chyb v našich vlastních algoritmech; a v tom, samozřejmě zhola žádný problém není.

Základní služby debuggeru jsou jednoduché a snadno jich můžeme využít přímo prostřednictvím grafického uživatelského rozhraní Xcode: do téže lišty, v níž se zobrazují chyby a varování při překladu, můžeme klepnutím myši na libovolný řádek umístit breakpoint, na němž se zpracování programu zastaví. Pak jen spustíme aplikaci příkazem "Build and Debug" (nebo jen "Debug", pokud víme jistě, že nechceme poslední změny ve zdrojovém kódu překládat):

Xcode otevře samostatné okno debuggeru a v něm spustí program. Na každém breakpointu se běh programu automaticky zastaví, a můžeme používat ovladačů v okně pro krokování programu, prohlížení obsahu proměnných a podobně.

Podívejte se na ladicí okno na posledním, třetím obrázku v tomto článku: lišta příkazů obsahuje ty nejčastěji používané služby (zvláště tedy "Continue", "Step Over" – která krokuje program, považujíc podprogramy a volání metod za atomické akce – a "Step Into", jež naopak do podprogramů a metod vstupuje). Zvláště pro ty, kdo pracují s rozsáhlými projekty, může být velmi zajímavá služba "Fix": ta umožňuje opravit zdrojový kód, a přenést opravu do laděného programu okamžitě – aniž bychom proto ladění ukončili a znovu spustili.

Ze dvou panelů pod příkazovou lištou je důležitější ten vlevo; v něm vidíme obsah zásobníku, tedy dynamický stav programu: seznam rutin a metod, jejichž kód vedl na současné místo v programu. Ty z nich, pro něž má debugger k dispozici zdrojový kód, jsou zobrazeny černě; můžeme na kteroukoli z nich klepnout myší, a v dolní části okna se zobrazí odpovídající kód. Panel vpravo obsahuje hodnoty hlavních proměnných aktuálního objektu i momentální rutiny; ty jsou docela šikovné, ale v praxi je mnohdy pohodlně nahradí konsole, o níž se zmíníme za chvilku.

V dolní části okna pak vidíme aktuální zdrojový kód se zvýrazněným řádkem, na němž se právě program nachází. V liště vlevo můžeme opět přidávat či rušit breakpointy. Chceme-li jen "o pár řádků popojet", není nutné přidávat dočasný breakpoint: stačí myší odvézt červenou šipku, jež označuje aktuální řádek, na požadované místo, a tam "pustit" – program se ihned spustí dál, a na místě, kde jsme šipku nechali se opět zastaví.

Pokročilejší programátoři jistě uvítají to, že Xcode neobsahuje vlastní proprietární debugger; namísto toho využívá zcela standardní a nesmírně silný ladicí program gdb. Jeho služby můžeme využívat prostřednictvím konsole; příkazem "Console Drawer" ji otevřeme, a v ní můžeme gdb řídit přímo pomocí jeho příkazové řádky.

Příkazů, jimž gdb rozumí, je nespočet, a nemůže je popisovat; jen se stručně zmíníme o těch nejdůležitějších:

• pomocí příkazu help získáme podrobné informace o jakémkoli dalším příkazu;
• příkazy p a po umožňují zobrazit hodnotu zcela libovolného výrazu (včetně výrazů, jež volají rutiny a metody z našeho programu!), jako čísla nebo jako objektu;
• příkaz condition dovoluje omezit breakpoint velmi obecnou podmínkou – běh programu se na daném místě zastaví pouze v případě, že podmínka je splněna;
• ještě bohatší služby nabízí příkaz command; jeho prostřednictvím můžeme libovolnému breakpointu přiřadit skupinu příkazů, jež se provedou kdykoli program na breakpoint narazí (na konci skupiny ovšem může být i příkaz continue, chceme-li, aby program bez přerušení pokračoval).