Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Proc jen na ty male? V Boot relativne nic nechybi, jen clovek musi udelat konfiguraci pro veci, ktere nejsou out of the box (coz by musel i na Springu v WAR)U větších projektů nejde o ten Spring Boot, ale o aplikační server – pro složitější aplikaci možná budete chtít více služeb aplikačního serveru, než poskytuje Jetty nebo Tomcat, a použijete třeba Wildfly nebo WebLogic, možná v clusteru.
Jo a pokud někoho zajímá, kde se to používá (spíše používalo) tak to byly systémy, kde se daly měnit zdrojové kódy za běhu. Kupříkladu Tomcat to možná dosud používá k tomu, aby uměl spustit novou verzi aplikace i bez restartu.Tam ale nepracujete s oběma verzemi třídy v jedné metodě najednou. Tomcat prostě používá víc classloaderů, jak je to ve specifikaci Servletů.
Jestli je u moderních VM nějaký pohodlnější mechanismus, to už nevím.Od Javy 9 k tomuhle slouží moduly ve spolupráci se ServiceLoader.
Kde tvrdím, že se soustřeďuji jenom na ošetření chyb a zapomínám kvůli tomu, že má program taky něco rozumného dělat? Nebo jak jste na to přišel?Netvrdíte to nikde, vy to přímo děláte – tady v komentářích. Přišel jsem na to tak, že jsem četl váš komentář.
Vhodné místo, kde řešit takovou událost, je v modulu, který zajišťuje komunikaci s tiskárnou - například formou if error && attempt_cntr-- => retry. Pokud tiskárna nereaguje, generuje chybu volajícímu, tedy asi vykreslujícímu kódu. Ten se podle toho zařídí po svém - např. uklizením svého kontextu a propagováním chyby ze své úrovně - zatímco komunikační úroveň zajistila konzistenci svého kontextu a hlásila nahoru chybu s komunikací, vykreslovací modul zajistí konzistenci na své úrovni a hlásí nahoru chybu při vykreslování písmenka X. Volající modul uklidí svůj kontext a propaguje výš chybu při pokusu vytisknout 5. písmenko 10. řádku 23. stránky. Teprve tady někde se o tom zpraví uživatel a případně se mu nabídne, co s tím dál. Může se třeba rozhodnout, že dokument počínaje 23. stránkou dotiskne na jiné tiskárně jak sám naznačujete, nebo překontrolovat tiskárnu a pokračovat v tisku stránkou, kde došlo k chybě apod. Ale pokud do této úrovně spadne nějaká low level chyba "printer communication error", tak co se s tím dá na této úrovni rozumného udělat, kromě "milý uživateli, tiskárna nekomunikuje, hroutím se k zemi"?Dobře jste popsal, jak fungují výjimky. Přičemž „volající modul uklidí svůj kontext a propaguje výš chybu“ je jedna z podstatných vlastností výjimek – ten volající modul nemusí o chybě vědět vůbec nic, jenom ví, že došlo k nějaké chybě, tak že má po sobě uklidit a propagovat chybu dál. Případně doplní k chybě další informace, pokud nějaké má. Další z výhod je, že až do toho místa vyřešení chyby doputuje ta původní low-level výjimka, takže je možné uživateli zobrazit detaily toho, co se stalo. Když to budete řešit návratovým typem, o tyhle detailní informace přijdete, budete tam mít tak maximálně „Chyba -1 – něco je špatně s tiskárnou“. A i to bude dobrý výsledek, protože to znamená, že vykreslovací modul počítal s tím, že bude vykreslovat na tiskárnu, tak pro to měl vyhrazený chybový kód.
Mám tomu rozmět tak, že kdybyste takový pdf-prohlížeč psal vy, tak při nějakém nahodilém zajiskření v konektoru se tisk zhroutí a musel bych běžet k tiskárně, abych zjistil, kam až a jestli vůbec se něco vytisklo, abych to pak mohl ručně poslat někam jinam nebo to zkusit znova, tipuji, že nejlépe celé od začátku? Děkuji pěkně, to teda píšete opravdu "velmi kvalitní a robustní" software.Máte bujnou fantazii, já jsem nic takového nepsal. Příště zkuste nehodnotit ostatní podle vašich vlastních hloupých nápadů.
Soustředíte se na nepodstatné detaily a ne na to podstatné, co chtěl ten autor říci, tj. že reakce na chybu je přes výjimky izolována od místa jejího vzniku, což tady někteří neustále vyzdvihujete jako přednost, ale podle mě je to zcela špatně, protože dochází k narušení a ztrátě kontextu.Ke ztrátě kontextu dojde jedině tehdy, pokud ten, kdo vyhazuje výjimku, kontextové informace do výjimky nezabalí. To, že reakce na výjimku je izolovaná od místa jejího vzniku, je správně – vychází to z principu jedné odpovědnosti, kdy každá ucelená část kódu (např. funkce) má dělat jen jednu věc. Pokud ten kód řeší například tisk, je už jeho zodpovědností ten tisk a neměl by řešit další věci, jako např. vypořádání se s výjimkou.
Kdybych reagoval v místě vzniku chyby, nepotřebuji balit informace o ní do žádného objektu, protože všechny dostupné informace o ní mám v rámci jejího kontextu k dispozici. A naopak - vyhození nějakého objektu - byť odvozeného speciálně pro danou úroveň - nemůže tuto informaci a ten kontext nahradit.V místě vzniku té výjimky nemusíte mít informace ani prostředky potřebné k vyřešení té výjimky. Zabalit informace o kontextu výjimky do objektu je sice pracné, ale pokud chcete na výjimku reagovat pořádně, nic jiného vám nezbývá. Ostatně když to porovnáte s vaším postupem – přibalit ty informace do návratového typu, musíte tam ty informace přibalovat také, a ještě navíc o to musíte rozšířit ten návratový typ.
to řešení přes try-catch-throw se mi vůbec nelíbí a myslím, že je velmi znepřehledňující a komplikující.To je možné, ale pořád je to milionkrát lepší, než když musím myslet na to, že tahle funkce sice podle logiky věci může vracet jen nezáporná čísla, ale někdo se rozhodl, že záporná v tom případě zneužije k hlášení chyb. Takže nejprve musím zjišťovat, zda vlastně funkce skončila úspěšně nebo neúspěšně, a pak musím paralelně vedle sebe řešit obě varianty. A navíc mám k zakódování informací o chybě k dispozici půlku integeru, to opravdu není mnoho.
Ale pořád je ještě spousta situací, kdy se testují podmínky v rámci samotného algoritmu - a tam mi try-catche jeho zápis neuvěřitelně zatemňují a komplikují.Asi bych potřeboval vidět konkrétní příklad, takhle netuším, co přesně vám připadá zatemňující a komplikující.
Při ignorování/zapomenutí ošetření chyb z bezprostředně nižší úrovně vnímám výjimky spíš jako debugovací nástroj, ale rozhodně nesdílím názor, který tu opět několikrát padl, že se na to v podstatě díky výjimkám můžu vykašlat a chytit ji někde o 3 úrovně výš. Takto programovat je podle mě prasečina. Důsledné používání principu reinterpretace a případné propagace reinterpretované chyby se mi osvědčil do takové míry, že výjimky vnímám takto negativně.Rozhodně by to nemělo být, že se na výjimku vykašlu – to, že jí budu beze změny propagovat dál, má být vždy vědomé rozhodnutí. Kvůli tomu třeba Java zavedla ty nenáviděné kontrolované výjimky – aby se jimi programátor musel zabývat. Programátoři to bohužel zvládají obejít i tak. Problém je v tom, že výjimka by se neměla reinterpretovat, spíš by se k ní měly nabalovat další informace – tj. jedna instance výjimky by postupně měla implementovat další rozhraní. S tím mají staticky typované jazyky problém.
"Požadovaný stav"? "Normální běh programu"? WTF?!To je typický pohled programátora s klapkami na očích. Pro všechny ostatní je samozřejmě nějaký běh programu normální, a to takový, kvůli kterému ten program používají. Třeba když si chce uživatel vytisknout PDF dokument, je normální běh PDF prohlížeče takový, že uživateli nakonec z tiskárny vyleze papír s vytištěným dokumentem. Můžete mít v programu ošetřené úplně všechny chyby, ale pokud se uživateli ten dokument vytisknout nepodaří, bude oprávněně nadávat, že ten program je k ničemu.
Žádný stav přeci není "požadovaný" a celý běh programu je "normální". Když si představím stavový diagram programu, nemám důvod některé uzly malovat nějak jinak. Program prostě reaguje a možné události a "chyba" je jen jednou z možných událostí. Záměrně píšu v uvozovkách, protože to je jen naše označení pro určitý stav. Ale to označení je dost zavádějící - chybou totiž ve skutečnosti je jakékoli neošetření/neuvažování možného stavu. Že mi nedojde paket je úplně stejně "normální" stav, jako že dojde. Pokud mám nabídku z 5 položek označených čísly 1-5, je stisk jakékoli klávesy stejně "normální". Přece není žádnou "chybou" pokud uživatel stiskne L a není důvod takovou situaci obsluhovat nějak zcela odlišně než číslice 1-5. Je to úplně normální situace, protože dotyčná funkce mi může vrátit cokoli, co se dá na klávesnici stisknout, a já s tím musím jako programátor počítat.
Jaký mají výjimky kladný efekt na návrh programu? Co je správného na reagování na určité stavy nějakým úplně jiným kanálem někde v úplně jiné části programu? Postnul jsem dva články, na něž Kit napsal, že autor výjimky použil chybně. A jak je to tedy správně?Správného je na tom to, že se na každý stav reaguje v té části programu, kde se na něj nějak reagovat dá. Například u toho tisku PDF může dojít k tomu, že v průběhu vykreslování stránky na tiskárnu dojde ke ztrátě spojení s tiskárnou. Vykreslovací kód s tím samozřejmě nic neudělá a ani s tím nic dělat nemá, na druhou stranu velice vhodné místo kde takovou událost řešit je kód pro interakci s uživatelem. Který může uživateli třeba zobrazit zprávu, že tiskárna bohužel přestala komunikovat, a nabídnout možnost vytisknout to na jiné tiskárně.
Ale tohle je přece něco naprosto jiného! Tady se bavíme o výjimkách jakožto syntaktické konstrukci v jazyce. Ne o výjimkách jakožto přerušení hlavního programu hardwarem.Nevím, co je naprosto jiného, protože já píšu právě o výjimkách jakožto syntaktické konstrukci v jazyce a odpovídající implementaci v přeloženém kódu.
Fragmenty typu if ((m = malloc(...))) nebo if ((f = fopen(...))) považuju za céčkové idiomy. Existují samozřejmě i chyby v alokaci jiného typu (lokální automatická data), ale to opět principiálně s jazykovými výjimkami nesouvisí.Ano, jsou to céčkové idiomy, ale to bohužel nezaručuje, že nenajdete kód bez toho ošetření. S jazykovými výjimkami to souvisí tak, že v céčku chybový stav můžete zachytit, když chcete – a když ne, tak chybu typicky hned v následujícím řádku kódu zazdíte. Výjimky jako jazyková konstrukce zajišťují, že nemůžete pouhým opomenutím chybový stav ignorovat – pokud výjimku neošetříte, probublá až někam do hlavní metody a (typicky) ukončí program. Pokud chcete takovou výjimku zazdít, musíte se aspoň trochu snažit.
Chyba se nejlépe ošetřuje právě tam, kde vzniká.To vůbec není pravda. Místo vzniku výjimky a místo jejího ošetření spolu nijak nesouvisí – někdy to může být to samé místo, někdy je to někde úplně jinde.
Ty na hlídání alokací kašleš?Ne. A výjimky mi dost usnadňují na něj nekašlat.
Taková chyba principiálně nemůže nestat. Transportní vrstva dodá buď bezchybnou zprávu, nebo nějakou chybu typu timeout při příjmu. Ale co je na tom výjimečného? To je na transportní vrstvě zrovna tak "normální" stav, jako poškozená zpráva na síťové vrstvě.Výjimky nejsou výjimečné tím, že by k nim docházelo výjimečně málo často, ale tím, že je to výjimka z normálního běhu programu, odchylka od toho, co chci, aby program dělal. K chybám při síťovém transportu může docházet hodně často, ale program je dělaný proto, aby data úspěšně přenášel – neúspěšný přenos je odchylka od tohoto žádaného stavu, proto je to výjimka.
Ked mam virtual server a jednu IP viem si nejak cez DNS A zaznamy na jednu IP priradit viacero domen? Kazdu na iny port?DNS A a AAAA záznamy ukazují pouze na IP adresu, ne na port. Na jednou IP adresu ale může odkazovat libovolné množství záznamů.
Tak puvodne jsem do teto diskuze nechtel prispivat, protoze je to zbytecne, ale toto jsem si nemohl nechat ujit. Kdyz se ten kod od PetrM prepise bez break a if-return, cte se to od shora dolu jako pohadka.Mohl byste jmenovat aspoň jednu pohádku, která má takhle blbou strukturu? Všechny pohádky, které znám já, mají jeden oblouk od začátku do konce. Ta vše pohádky by musel vy padat takhle nějak:
Žili byli v jednom království princ a princezna. Princezna byla krásná … zlá královna … zrcadlo … otrávené jablko … princezna spí … švarný princ ji políbil … princezna se probudila. Byla veliká převeliká svatba,a žili spolu šťastně až do smrti. Zazvonil zvonec, a pohádky je konec. Jo aha, ještě ten princ ze začátku pohádky. Ten žil taky šťastně až do smrti. Pohádky je konec.
Takze vlastne budeme pouzivat strukturovane programovanie tak, ze poprieme cyklus, vetvenie a sekvenciu.Ne, to tady nikdo netvrdí.
Cize cyklus nie je cyklus, ale len tak ho v polke sekneme breakom, miesto miesta, kde sa ma.(lebo kod je dlhy, naco by sme vytvarali dalsie procedury)Když v půlce cyklu zjistíte, že nemá smysl (nebo se dokonce nesmí) zbytek těla cyklu provádět, tak iteraci ukončíte a pokračujete na další. Nechápu, co vám na tom připadá divného. Tím, že celý zbytek cyklu dáte do ifu, na kódu nic nevylepšíte, nanejvýš to bude nepřehledné – a ten cyklus tím „seknete v půlce“ úplně stejně. Tím, že obsah toho ifu dáte do samostatné funkce, si ne vždycky pomůžete. Zaprvé jste tím ifem pořád „seknul cyklus v půlce“, za druhé to může znepřehledňovat kód, za třetí to kód může zpomalovat. Protože volání funkce není zadarmo, zvlášť když k tomu budete potřebovat další data, která se budou muset do funkce zkopírovat. Také může volání funkce zabránit odrolování smyčky optimalizátorem. Nespoléhejte na to, že vám kompilátor funkci pokaždé inlinuje, zvlášť když používáte divné konstrukce svého vlastního programovacího paradigmatu.
A je to vpohode, lebo c-cko a java napriklad obsahuje break vo switchi.(Co je jazykovo specificke a sposobuje to bugy)Ne, C ani Java neobsahují break ve switchi. C i Java obsahují break, který vyskočí z aktuálně prováděného bloku kódu – přičemž tím blokem může být například cyklus, switch nebo blok s návěštím. Ten break je ale pořád úplně stejný, ve všech třech variantách – break ve switchi není ničím zvláštní. Tváříte se jak mistr světa, chcete ostatní poučovat o strukturovaném programování, ale break je pro vás zjevně obestřen tajemstvím…
Trosku preskocime nieco s goto, vsak nic sa nedeje.goto sem pořád motáte akorát vy.
A mame 10 returnov z funkcie, aby smudla hladal, ze ktory to bol.Proč by to měl hledat? Z venku má funkce dělat jednu věc a jestli je v ní jeden return nebo 10 returnů má být volajícímu jedno. Pokud to pro volajícího jedno není, je ta funkce špatně napsaná.
Potom odchytime vynimku na poslednom moznom mieste, lebo zvysny kod nie je dolezity a koder si moze dohladavat, preco sa veci nevykonali.To, že se nějaký kód po vyvolání výjimky nezavolal, je správně, je to záměr – třeba když se vám nepodaří alokovat paměť, bylo by špatně do ní zapisovat.
Vsak kompilator to vsetko aj tak prelozi na skok.Jistě. Už jsem vám to psal několikrát, že bez skoků byste toho moc nenaprogramoval.
If je aj tak skok, dame tam goto.goto tam dáváte jenom vy, nikdo jiný tady o něm nepíše.
Ano, je to ono, vlastne mate pravdu, to len ja zle interpretujem. (To bola ironia).No, ono to spíš vypadá, že problém není v interpretaci, ale v tom, že strukturovanému programování prostě vůbec nerozumíte. break je pro vás záhadou, netušíte, co dělá, tak jste si radši zavedl pravidlo „break nepoužívat“. Pak jste někde zaslechl, že se nemá používat ani goto, a teď si kvůli tomu goto a break pletete. A asi jste zrovna objevil, co dělá return, tak jste se hned v diskusi chtěl pochlubit „dobrou“ radou – no a ten break jste k tomu přihodil, protože netušíte, co dělá, tak co kdyby se s ním dalo i vyskočit z funkce.
Podla mna mate v hlave len nejaky neurcity obraz o strukturovanom programovani. Aby ste boli kludny, nazvem to "Jirsakove strukturovane programovanie", aby sa to neplietlo.O balkiho strukturovaném programování mám zatím opravdu jen velmi neurčitý obraz. Zatím o balkiho strukturovaném programování vím jistě akorát to, že z procedury lze vyskočit returnem i breakem a že break ve switchi má speciální chování, ale když se použije někde jinde, změní se na goto.
Ale kdepak. Ja jsem to formuloval jako vicemene nepsana, lety osvedcena, pravidla pro pekny strukturovany kod. To ostatni, vcetne tve malickosti, z toho zacali delat dogmata, pseudopravidla a nejvetsi nestesti na teto planete hned po globalnim oteplovani.Dogma z toho dávno před vámi udělal balki. Vy jste byl mírnější, označujete to jen za pravidla pro pěkný kód – jenže ani to není pravda. Na použití break nebo continue nebo na použití vícenásobného returnu není a priori nic ošklivého. Ano, dá se to použít ošklivě, jako každá konstrukce, a stejně tak existují konstrukce, kde je takové použití přirozené a vede to na pěkný strukturovaný kód – a pokoušet se těm konstrukcím vyhnout by ten kód jen znepřehlednilo.
Zacinajici programator, stejne jako behajici dite, takove veci nemusi hned napoprve domyslet.Ovšem nijak mu nepomůže zavádět ho do slepých uliček tím, že budete tvrdit, že problém je jinde, než ve skutečnosti je.
Je zajimave, ze vsichni mistni machri neustale mlcky prechazi problem puvodniho tazatele a ignoruji skutecnost, ze kdyby nepouzil predcasne vyskoceni z funkce, problem by proste nebyl.Vy jste mu snad radil, než se tady zeptal, ne? Tazatel původně hledal problém ve vyskočení z funkce, tak také formuloval svůj dotaz – a po několika dotazech na podrobnosti se ukázalo, že problém vůbec není ve vyskočení z funkce, ale ve způsobu, jak tazatel používá zámky. Z toho, ke je vlastně problém, byl tazatel zmatený dost, nemusíte ten jeho zmatek ještě podporovat.
Pokud se nachazim ve spolecnosti (jmenovite PetrM a Cikada), kde je i zasada, ze funkce by mela delat prave jednu vec, povazovana za vadnouTo jsem asi přehlédl, pomohlo by, kdybyste přidal odkazy.
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.