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:

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:

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 …