Tak za takovýhle kód bych vraždil. Pokud uzavírám stream, socket, a já nevím co všechno ještě, vždycky ve finnaly bloku. Možná budete namítat, že tohle je jen "ukázkový zdroják", ale pak k vám přijde do týmu nějaký ucho, co se učí z článků na internetu a dělá takovýhle prasárny a diví se, že má stovky neuzavřených connection třeba na databázi.
Asi tak, další dobrá věc kterou není radno opomíjet je flush() :)
Shodou náhod zrovna psal někdo na builder.cz, že má ORA-01000 musel jsem se začít smát :D
A to jako proc? Protoze si to tak nekdo pred 30-ti lety rekl? Stream jako stream, jediny jeho atribut je, zda-li je vstupni, vystupni nebo pro jistotu oboji...:) (ano i takove Stremy existuji a jsou implementovane)
Nepochopil jste... ja se ptam, proc zrovna stream s FD 2, proc ne treba 8... to, co popisujete se tyka neceho jineho a sice (dle Vas nemoznosti) demultiplexovat data z jednoho streamu... (i to je kupodivu jednoduse mozne)
Po přečtení následujících komentářů je mi jasné, že s vámi je zbytečné se bavit, ale dneska mám dobrou náladu.
Takže, představme si výstup na konsoli z nějakého prográmku na zpracování speciálních obrázků:
$imageprocess: -i image.bin -offt image.fft -ostats image.stats
Processing Image
[Warning] Image file is in deprecated format, version 0.5.
[Warning] Image does not contain statistical information.
Starting Fast Fourier Transformation...
[Warning] Image size is not compatible with FFT, cropping image.
Done
Gathering Statistical Information...
Done
image.fft Saved
image.stats Saved
Takhle by to vypadalo po vypisu všeho do System.out. A to jsem vzal ještě mírnější versi, kde nenastaly ty "velké chyby", kterých může být klidně přes sto. Uživatel ví, že obrázek není čtvercový a že se bude ořezávat, uživatel ví, že v obrázku staré verse nejsou statistické informace. Proto preferuje výpis:
Suhlas. Tiez myslim, ze ked uz sa uvazuje rozdeleni vypisov podla ucelu, je namieste pouzit niektori logovaci system - najcastejsie log4j alebo priamo API v JDK 1.4 a vyssie.
Tedy přece nejde o žádné sofistikované logování. Jde o prosté vypsání chybových hlášení. U takto jedoduchého programu by myslím bylo zavedení nějakého speciálního logování spíše na škodu.
Tak jak tak, chybové hlášení patří na standardní chybový výstup. Na tom trvám.
A ja pro zmenu trvam, ze chybove hlasky patri tam, kam je ocekava obsluha, aby na ne mohla aktivne a adekvatne reagovat... coz je treba remote konzola, nejake sofistikovane zarizeni, soubor atd... - to, ze lze zajistit presmerovani FD 2 na jine (s omezenimi) je z historickych duvodu a neodpovida soucasnym potrebam... - log4j je dobry priklad, jak to resit... To, ze Cckari tuto vymozenost bezne neznaji, jednoduse proto, ze GLIBC nic takoveho neobsahuje, neznamena, ze tato potreba neni i zde... - treba ovladani technologickych procesu (jichz jsem se ucastnil) bylo sice implementovano v C, ale jiz pred 15 lety byly potreby naprosto shodne s tim, co umoznuje log4j... - (log4c neexistovalo) takze opakuji - stderr je hezky, historicky, ale neodpovida casto potrebam... zejmena pokud potrebujete dalsi veci - muzete mi rici, jak FD 2 "presmerujete" do Event loggeru ve Win32 platforme?
Grep je dobry ked vies co hladas. Ty ovladas napr. vsetky chybove hlasky Apacha (aj s pluginmi)?
Samozrejme ze chyby patria do file descriptora 2 aby sa dali oddelit alebo do samostatneho error kanala v logovacom baliku.
Ano, pretoze su to zauzivana standardy a este aj dnes velmi pouzivane. Preco prepinanie medzi oknami niekto nezmeni v kazdej novej verzii Windows. Preco F1 je help... to su zauzivane standardy a o potrebe oddelenia chyboveho a standardneho vystupu sa nebudeme bavit.