V debuggovacím režimu trávím poměrně dost času. Znáte to - něco je špatně, junit testy tvrdí že je vše OK, integrační testy padají a nikdo neví proč. Postupně tedy lokalizujete možné místo problému a pro ověření stačí daným místem projít. S tím správným uživatelem. A session v určitém stavu. A načtenou konkrétní konfigurací a jako bonus nesmíte dělat změny v DB sdílené s ostatními vývojáři.

Nasimulovat takové podmínky není vždy jednoduché, často jsem to řešil přímo několika vloženými řádky do kódu, což tedy znamenalo nový cyklus kompilace a redeploye. Pak jsem zjistil, že potřebuju změnit další proměnnou a vše se opakovalo, než se mi podařilo chybu nasimulovat a opravit. Nudné, dlouhé.

Později jsem objevil kouzlo breakpointů, kdy si můžu prohlédnout stacktrace, hodnotu proměnných a hlavně i tyto hodnoty měnit - buď přímo, nebo pomocí expressions - v Eclipse jsou pro tyto dvě možnosti samostatné záložky. To mi nabídlo poměrně velkou flexibilitu a hlavně jsem se zbavil redeploye. Ale stále tam byl ten breakpoint a nějaké to manuální klikání hodnot, během něhož může vypršet limit pro připojení do externích systémů (hlavně DB, kdy tak držíte zamčené tabulky). Že to funguje dobře jen s jednoduchými typy nebudu ani zmiňovat, proxy a podobné instance jsou nedostižné.

Posledním objevem jsou conditional breakpoints. Jedná se o normální breakpoint na řádce s tím bonusovým přídavkem, že k němu můžete dodat podmínku, kdy se má vykonávání programu opravdu zastavit a kdy program pokračuje dál, jakoby tam žádný breakpoint nebyl. Tohle použijete v případech, že je breakpoint na nějakém frekventovaném místě, ale vy chcete debuggovat pouze konkrétní kontext (např. Dao metoda s miliardou parametrů a jeden z nich dělá problémy, když je prázdný). Ale lze zajít ještě o krok dál ...

Podmínkou u breakpointu může být takřka libovolný kód, pouze musí vracet true/false, chováním tak trochu připomíná AOP. Ale jednoduchá ukázka obrázkem udělá víc, než slova - modelový příklad představuje vypršení session uživatele (v konzoli jsou vypisovány informace o tom co se děje). Nejprve je kód spuštěn s vypnutým breakpointem:

Debug run vypnutý

 

Následně nechám tu samou aplikaci proběhnout ještě jednou, tentokráte s aktivním breakpointem, který simuluje déle přihlášeného uživatele a zároveň nezastaví vykonávání programu:

 

Debug run spuštěný


Výpis v konzoli prozrazuje, že vše proběhlo opravdu ihned, kód aplikace zůstal nezměněn a byl proveden kód v podmínce breakpointu. Co vše s tím můžete dělat už nechám na vás, jen dodávám, že vyhodnocení podmínky stojí trochu bokem a tak je potřeba použít v některých případech plně kvalifikovaná jména.

Proklikejte si záložku s breakpointy. Některé kolegy zarazila i možnost dát podmínku nikoliv na konkrétní řádku, ale na vyvolání new *Exception ...