Přesně tak jsem to myslel – ne vyhodit výjimku ať ji zpracuje někdo jiný, ale zpracovat ji stejným způsobem, jako výjimky obvykle zpracováváte, s přihlédnutím k tomu, že se pohybujete na tenkém ledě metody finalize().
Filip Jirsák Dne 28. ledna 2010 12:50 Kamil Podlesak <[email protected]>napsal(a): > Tady bych opravil: výjimku ve finalize() zapsat do logu, vyhodit ji > nemá moc smysl (to je právě jeden z problémů finalize: co se stane > když vyletí výjimka?) > > Jinak tuto praktiku vřele doporučuji, samozřejmě je pak nutné nechat > nějak automaticky sledovat (grepovat) aplikační log na produkci a > nalezené chyby opravovat. > Spoléhat na programátorskou disciplinu je _velmi_ deprecated :-) > > Kamil Podlešák > > 2010/1/28 Filip Jirsák <[email protected]>: > > Ještě doplním, že může být vhodné tu pojistku doplnit assertem, který > > upozorní na to, že někdo někde tu úklidovou metodu zavolat zapomněl. > Záleží > > pak na kontextu, jestli tohle stačí, nebo jestli je k tomu potřeba si > > táhnout nějakou další informaci – typicky v konstruktoru si (pod > assertem) > > vytvořit výjimku, uložit si ji, při zavolání close() ji vymazat a ve > > finalize() otestovat její přítomnost, a pokud výjimka existuje, vyhodit > jí. > > > > S pozdravem > > > > Filip Jirsák > > > > -- > > [email protected] > > > > > > Dne 28. ledna 2010 11:44 Zdenek Tronicek <[email protected]> > napsal(a): > >> > >> Aplikacni programator udela nejlepe, kdyz na finalize() zapomene a misto > >> nej bude pouzivat metodu pro uklid a try + finally: > >> > >> InputStream is = ... > >> try { > >> ... > >> } finally { > >> is.close(); > >> } > >> > >> Pokud jde o to, zda ma finalize nekdy smysl, tak ano: muze to byt > pojistka > >> pro pripad, ze programator zapomnel zavolat uklidovou metodu. > Programator > >> by na to ovsem nemel spolehat a mel by se snazit, aby kazdy objekt po > sobe > >> uklidil. > >> Jinak ten clanek, ktery uvadis, je z roku 98. Takze to asi nebude > >> nejvhodnejsi zdroj. > >> > >> Z.T. > >> -- > >> Zdenek Tronicek > >> FIT CTU in Prague > >> > >> > >> Ondra Medek napsal(a): > >> > Ahoj, > >> > > >> > navazuji tak trochu na predchozi thread. Jsem ted zmaten, jesli ma > >> > Object.finalize() smysl nebo by mel byt @Deprecated. Pokud ma smysl, > >> > tak kdy ho pouzit? > >> > > >> > V JDK 1.6 JavaDoc dokumentaci > >> > > >> > > http://java.sun.com/javase/6/docs/api/java/lang/Object.html#finalize%28%29 > >> > stoji: > >> > > >> > "For example, the finalize method for an object that represents an > >> > input/output connection might perform explicit I/O transactions to > >> > break the connection before the object is permanently discarded." > >> > > >> > Clanek ja Javaworld > >> > http://www.javaworld.com/javaworld/jw-06-1998/jw-06-techniques.html > >> > tez radi ve finalize() uvolnovat systemove zdroje, ale pouze jako > >> > "fallback mechanism". (Coz mi presne sedi pro ten java.awt.Window > >> > problem). > >> > > >> > Progrepoval jsem JDK 1.6 zdrojaky a SUN se k finalize() asi stavi > >> > ambivalentne: nekde ho pouziva, nekde ne. Priklady pouziti: > >> > java.util.zip.ZipFile - zavira IO stream > >> > java.io.FileInputStream + java.io.FileOutputStream : zaviraji file > >> > descriptory > >> > ... a dalsi > >> > > >> > Nejvice je onen ambivalentni pristup videt na ImageInputStreamImpl a > >> > FileImageOutputStream z baliku javax.imageio.stream: > >> > ImageInputStreamImpl ma finalize(), ktere v podstate jen nastavi > >> > priznak isClosed = true > >> > FileImageOutputStream je potomek ImageInputStreamImpl a prepisuje > >> > finalize(), ve kterem nedela nic. > >> > > >> > Dale jsem nasel treba zakomentovany finalize(), ktery puvodne zavitral > >> > IO stream, v com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl s > >> > poznamkou, ze "It affects the performance greatly in multi-thread > >> > environment. ". Tedy ZipFile vesele IO stream zavira ve finalize(), > >> > kdezto CoreDocumentImpl to ma zakomentovane. > >> > > >> > Diky > >> > Ondra Medek > >> > > >> > > > > >
