Warning: WP_Syntax::substituteToken(): Argument #1 ($match) must be passed by reference, value given in /data/www/15070/dadajax_net/www/wp-content/plugins/wp-syntax/wp-syntax.php on line 383
Warning: WP_Syntax::substituteToken(): Argument #1 ($match) must be passed by reference, value given in /data/www/15070/dadajax_net/www/wp-content/plugins/wp-syntax/wp-syntax.php on line 383
Warning: WP_Syntax::substituteToken(): Argument #1 ($match) must be passed by reference, value given in /data/www/15070/dadajax_net/www/wp-content/plugins/wp-syntax/wp-syntax.php on line 383
Už delší dobu mám v plánu napsat podobný článek. Často totiž narážím na případy, kdy především začátečníci s výjimkami nakládají velmi špatně. O co jde? Uvedu první příklad:
try { Thread.sleep(100); } catch (InterruptedException e) { } |
V uvedeném příkladu se v bloku try se zavolá příkaz na uspání vlákna na dobu 100ms. To může vyhodit InterruptedException. Na tuto výjimku máme možnost zareagovat v bloku catch, ale jak vidíte, tento blok je prázdný. V čem je tedy problém? Pokud na výjimku nijak nezareagujeme, koledujeme si o pořádné problémy. Pokud dojde k problému, nebudeme o tom vůbec vědět a aplikace se bude chovat divně. Taková chyba se hledá opravdu špatně a není vůbec lehké ji proto najít. Mnohdy taková chyba spustí řetězovou reakci spoustu dalších chyb.
Další příklad, který nyní uvedu, je oproti tomu předchozímu lepší, nicméně stále nedostačující:
try { Thread.sleep(100); } catch (InterruptedException e) { System.out.println(„Nepodařilo se uspat vlákno“); } |
V tomto případě v momentě vyvolání výjimky sice dostaneme informaci o tom, že se něco nepodařilo, ale neřekne nám to téměř nic podstatného. Neznáme totiž žádné detaily této výjimky.
Správné řešení
Pokud nechcete strávit spoustu bezesných nocí nad laděním nefunkční aplikace, silně doporučuju použít tento způsob:
try { Thread.sleep(100); } catch (InterruptedException e) { e.printStackTrace(); // další metody pro ošetření výjimky } |
V tomto případě se v momentě vyvolání výjimky vypíše na standardní výstup stack trace (zásobník volání metod). Tam můžete jednoduše zjistit místo, kde k chybě došlo a často se zde objeví i popis problému. Samozřejmě že to není jediná možnost, dále můžete použít například různé logovací knihovny (například Log4J), které mají své funkce na výpis a logování těchto informací.
Nebuďte tedy líní a vždy v bloku catch nechte vypsat stack trace. I v případech, kdy si myslíte, že k výjimce dojít nikdy nemůže (což je stejně naivní jako třeba spoléhat se na to, že když si namíříte mezi oči nabitou a odjištěnou zbraň a zmáčknete spoušť, zbraň se pokazí a nevystřelí). Ušetříte tak sobě i svému okolí spoustu hodin, které byste jinak promarnili řešením podivného chování aplikace 🙂
A až budete řešit problém, se kterým si nebudete vědět rady, jednoduše zkopírujete výpis ze stack tracu do nějakého fóra a vaše šance na vyřešení problému se mnohonásobně zvýší. Není totiž nic horšího, než když programátor popíše problém slovy „nejde to“, nebo „píše to nějakou chybu“. Ale to už je na další článek 😉
Hele, nechcu ti do toho kecat (vlastně chcu bo jinak bych tu nespamoval) ale píše se Jawa… 😀
To uváděné „správné“ řešení mi tedy moc správné nepřipadá, protože ignoruje skutečnost, že v řadě knihovních funkcí opravdu nestojíš o to, aby je někdo přerušoval, ale mají nezávisle na přerušení řádně doběhnout a nechat rozhodnutí a případném přerušení na tom, kdo je volal.
Správné řešení pro univrzální čekací metodu je
try {
Thread.sleep(100);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
Tím přerušení ošetříš a ten, kdo metodu volal se může rozhodnout, co s tím.
Potřebuješ-li ukončení akce zrychlit, můžeš sice vložit do ošetření i return, ale většinou je opravdu žádoucí, aby se akce řádně dokončila a volajícímu se předala informace o tom, že tu byla žádost o přerušení.
rudymet: Děkuji za opravení. Abych řekl pravdu tak jsem ten příklad s InteruptedException použil čistě náhodou (byl první na co jsem si vzpomněl) a jak to tak vidím tak to k něčemu bylo. Alespoň jsem se dozvěděl něco nového. V tomto článku jsem se o této problematice dozvěděl trochu víc.
Takže až na nevhodně zvolený příklad je článek doufám správně a třeba díky tomu někdo přestane polykat výjimky 🙂
Díky! 🙂