Nejjednodušší bug-report v Delphi - Builder.cz - Informacni server o programovani

serial

serial

9. května 2002, 00.00 | Chybuje vaše aplikace? A co si ji takhle trochu ohlídat. Bug-report a logování se může stát vaším dobrým společníkem při boji proti nečekanému.

Asi každý kdo někdy udělal nějakou aplikaci resp. prográmek se setkal s tím, že v jistých případech jeho miláček selhal. Mohlo to být zaviněno, jak chybou vyvolanou v důsledku špatného software na klientském počítači tak i chybou, která programátora vůbec nenapadla.

Každý vývoj software provázejí neočekávané výjimky. Když jste ve fázi vývoje či ještě jste na Alfa testingu, tak to není takový problém, protože často sám programátor dokáže dohledat, kde a proč ona výjimka vznikla.

Problém však může nastat už v Beta testingu. Najednou se software přesune k někomu jinému, který vesměs nemůže kompletně a často ani nechce odlaďovat zdlouhavé kódy aplikace. Ještě horší případ může nastat, když se takovéto chyby začnou objevovat ve finální verzi aplikace.

Nejlépe je se jim vyhýbat. To je rada nad zlato, co? V podstatě každý sebelepší program má nějakou chybu. A podle jednoho pořekadla platí, že nemá-li program žádnou chybu, pak sám je chybou.

Je jasné, že většina takovýchto výjimek nastává v místech opravdu zcela neočekávaných, takže ani v programu není nijak ošetřena. Tzn. není zde často žádný blok try či asserce anebo nějaké naše inteligentní ošetření výjimky. To má však jeden neblahý důsledek, bez tohoto ošetření, lze v podstatě tak akorát zjistit, že nastala výjimka a případně její druh resp. zprávu.

A právě tohoto využívají bug-reporty, které si jednotlivé výjimky shromažďují do svých databázových souborů. Kde se do nich snaží uložit co nejvíce informací, které lze o výjimce získat.

Velmi jednoduchý bug-report lze dodělat bez větší námahy i do aplikace v Delphi. Stačí pouze si pohlídat Application.OnException. Samotné ošetření, pak lze realizovat v mnoha variacích. Základně by, ale všechny měli nějakým způsobem zapsat onu výjimku do logu¹. Na to by se aplikace měla sama nějak inteligentně rozhodnout zda aplikaci bezprostředně ukončí či ji ponechá na živu. Pro ozřejmení, ne všechny vzniklé výjimky budou kritické pro běh aplikace. Např. takové přetečení integeru často nebývá kritické, obvykle způsobí jen malé škody.

V základu by tedy takové nejtriviálnější ošetření mohlo vypadat takto:

Již jsem se zde zmiňoval o log souboru. U složitějších projektů či u aplikací náchylnějším k chybám je mnohem vhodnější ještě vytvořit tzv. logovací systém. Takovýto správně udržovaný log pak může být neocenitelnou studnicí vědomostí při hledání daných chyb. Lze totiž do něj v průběhu běhu aplikace zapisovat (bez vědomí uživatele) jeho jednotlivé kroky. Takže když se najednou vyskytne chyba, vy si krásně můžete přečíst vše co udělal uživatel od spuštění aplikace, tak velice přesně zjistíte, kde nastala chyba.

To jeden z nejlepších způsobů jak na takovéto výjimky reagovat. Problém zde ovšem vyvstává v tom, že celý tento proces vyžaduje dost úprav zdrojových kódů. A pravděpodobně ani nepůjde dobře implementovat do již existujících projektů, které s ním nepočítaly.

V neposlední řadě by všechny takto získané informace měli být odeslány k programátorovy. Jinak by celé naše snažení nějak postrádalo smysl. Uživatel sám těžko odešle nějaký soubor na nějakou adresu, i když mu to budete připomínat denně. Takže nezbývá nic jiného než zeptat se uživatele (ať již při vzniku výjimky či při dalším zpuštění aplikace) jestli s odesláním tohoto souboru souhlasí. A pokud ano, tak vše odeslat.

V poslední řadě byste si měli sednout k počítači a přečíst si daný email. Podrobit ho své analýze, po které rozhodnete, zda ho hodíte do koše či jste opravdu odhalil chybu ve vašem kódu.

1. – První zádrhel: nelze zapsat nedostatek místa na disku.