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 >> > >> > >
