Příspěvky

241

Vývoj / Re:C++ a výjimka v destruktoru

« kdy: 07. 02. 2014, 15:56:24 »

Programování obecně vyžaduje kázeň a zejména dodržování různých pravidel a dbát na koncepci a organizaci celého projektu. Platí pro C i pro C++. Chápu, že profesionálové dlouhé léta pracující v C se neradi přeučují na něco jiného. Protože ono se v C++ opravdu programuje úplně jinak. Ale i to vyžaduje kázeň, protože je sice spoustu věcí, které za vás C++ udělá, ale zase je třeba mít o tom přehled, rozumět tomu a vědět co dělám a proč to dělám. Když Cčkař začne kritizovat už jenom třeba fungování obyčejného destruktoru s tím, že nikdy neví přesně, co se uvnitř děje, pak ... já ho celkem chápu ... ale buď musí na sobě pořádně zapracovat, aby se v C++ naučil, a nebo ať to tedy dál matlá v tom Cčku no.

242

Odkladiště / Re:Nápad, cena mědi = měna nebo spíše jen nová digi měna.

« kdy: 07. 02. 2014, 15:41:00 »

recese je to dobrá.

Obdivuju, že se někdo s něčím takovým dělal. Já na to ten čas nemám. Ale bacha, aby někdo ty prachy nakonec neposlal a vy měli na krku nějaké to trestní oznámení.

243

Vývoj / Re:C++ a výjimka v destruktoru

« kdy: 07. 02. 2014, 15:24:30 »

Bez pochyby neni sporu o tom, ze vyjimky v destruktoru prinasi vic skody nez uzitku.

To jsou vaše závěry, ne moje

PS: Co takhle udelat nejake hlasovani? 1. otazka: Je to dobre? 2. otazka: chteli byste s takovym kodem pracovat?

OLOL 

Mno a na zaver ...

http://c2.com/cgi/wiki?BewareOfExceptionsInTheDestructor

IMHO ten začátek je legrační

• Objects with throwing destructors cannot be used in Standard containers
• Objects with throwing destructors cannot even be composed safely
• In the new C++11 standard all throwing destructors terminate the program, even when not UnwindingTheStack

Ad 1) nejdou použít protože to zakázali. Zakázali to, protože nejdou použít... tomu se říká cyklus
Ad 2) [citation needed]
Ad 3) Je obecně špatný krok v normě asi tak jako by vědci prohlásili, že kvantovou fyziku stejně nikdo nechápe, takže ji radši zrušíme.

244

Vývoj / Re:C++ a výjimka v destruktoru

« kdy: 07. 02. 2014, 12:26:39 »

Ja myslim ze byste si meli precist toto:

"Cleaner, more elegant, and harder to recognize"
http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx

(Yes, there are programming models like RAII and transactions, but rarely do you see sample code that uses either.)

Tahle poznámka vypovídá o všem. Článek nedoporučuju.

245

Vývoj / Re:C++ a výjimka v destruktoru

« kdy: 07. 02. 2014, 12:23:23 »

Ja myslim ze byste si meli precist toto:

"Cleaner, more elegant, and harder to recognize"
http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx

Četl jsem. Předně "The Old New Thing" není žádná celebrita. Občas tam má zajímavé postřehy, občas tam má totální blbosti, jako v tomto případě. Nehledě na to, že ty příklady na špatné kódy má na konci v nějaké C#, v lepším případě.

Nemůžeš ignorovat vývoj.

246

Vývoj / Re:C++ a výjimka v destruktoru

« kdy: 07. 02. 2014, 11:48:12 »

Pokud musi programátor používat i kód od amaterů, tak jistě máte pravdů, od toho mám SEH
(http://novacisko.blog.root.cz/2012/09/05/seh-v-linuxu-c/)

V tom případě si napište i vlastní kernel, protože v něm jsou bezpečnostní chyby taky.

A teď o té červené karkulce.

247

Vývoj / Re:C++ a výjimka v destruktoru

« kdy: 07. 02. 2014, 10:47:04 »

Profesionální programátorovi program nespadne. Nikdy. Program by neměl padat. Na výjimečnou situaci se reaguje výjimkou

Profesionální programátoři používají v serverech mimo svého kódu i generické komponenty, ve kterých jsou bohužel známé i neznámé bezpečnostní chyby. Se zapnutým binary hardening, což je na serveru dobrý nápad, vede pokus o exploit na crash.

Pokud musi programátor používat i kód od amaterů, tak jistě máte pravdů, od toho mám SEH
(http://novacisko.blog.root.cz/2012/09/05/seh-v-linuxu-c/)

248

Vývoj / Re:C++ a výjimka v destruktoru

« kdy: 07. 02. 2014, 09:53:22 »

Sorry ale navrhovat servery s tim, ze kdyz to spadne vyspawnujeme novyho workera neni hodne profesionalna.

Sorry, ale navrhovat server s tím, že crash jednoho threadu mi shodí celý server, není hodné profesionála.

Profesionální programátorovi program nespadne. Nikdy. Program by neměl padat. Na výjimečnou situaci se reaguje výjimkou

249

Vývoj / Re:C++ a výjimka v destruktoru

« kdy: 07. 02. 2014, 07:15:27 »

Troluješ ty, SIGSEGV nebo 500 vyjde pro uživatele úplně nastejno a když na serveru spadne worker, vyspawnuje se místo něho nový, takže to postihne taky jednoho uživatele. Mimochodem cílem by nemělo být "nějak to zbastlíme a když občas někdo dostane 500, tak je to jedno, ve statistiká se to přece ztratí", ale "vytvoříme robustní řešení schopné definovaně ošetřit a reportovat chybové stavy (i více, ne jen první)".

Prefork patri do minuleho stoleti. Dneska jsou servery threadove. Jejich nevyhodou je, ze kdyz spadne jeden thread, vezme s sebou ostatni. Vyhodou naopak je vyssi rychlost (razeni vlaken je snazsi nez procesu) a takova kompaktnost aplikace, jako ze jednotliva vlakna mohou sdilet data, mohou snadno spoustet a ridit joby a podobne. Klade to vyssi naroky na stabilitu cele aplikace, tedy aby kazdy problem byl osetren a zareportovan, protoze sestreleni threadoveho serveru muze byt dost fatalni.

Sorry ale navrhovat servery s tim, ze kdyz to spadne vyspawnujeme novyho workera neni hodne profesionalna.

250

Vývoj / Re:C++ a výjimka v destruktoru

« kdy: 07. 02. 2014, 02:18:46 »

A preco by sa mal server zlozit, ked nieco nefunguje? Pri chybe nie je vzdy nutne vyhadzovat vynimku - vsak su aj Cckoidne riesenia chyby. Niekedy staci goto, inokedy je mozne vratit chybovy stav (ci uz hnusne cez zdielanu premennu - errno) alebo navratovou hodnotou alebo ulozenie niecoho na pointer dodany v parametroch.

protože

Kód: [Vybrat]

void readPage(Request *r) {
    char buffer[1000];
    FILE *f = fopen(r->pathname,"r");
    int i = fread(buffer, 1000,1,f);   //crash SIGSEGV
   //...
    fclose(f);

}

ale

Kód: [Vybrat]

void readPage(Request *r) {
    char buffer[1000];
    FileStream f(r->pathname); //exception - FileNotFound exception
    int i = f.read(buffer, 1000);  
   //...

}

... {
    try {
       readPage(r);
   } catch (FileNotFoundException &e) {
       errorPage(404);
   } catch (...) {
       errorPage(500);
   }
}

Jasně, Cckové řešení vyžaduje ošetřit návratovou hodnotu z fopen. A pak nějak vrátit chybový kód tomu volajícímu. Výjimka takové povinnosti eliminuje. Ať už funkce readPage dělá cokoliv (může být abstraktní, implementovaná v potomkovi), pokud vyhodí FileNotFoundException, pošlu na výstup status 404 Not found. Všimněte si také, že výjimkové řešení bude o několik řádek kratší. A v neposledním případě, výjimkové řešení je rychlejší, protože kód neobsahuje zbytečné testy na každém rozcestí, obsahuje jen vyhodnocení místě vzniku chyby a pak vyhodnocení při výjimce. Výjimky se totiž řeší bokem, mimo hlavní kód... tedy vrací se jinou cestou, než původní kód.

251

Vývoj / Re:C++ a výjimka v destruktoru

« kdy: 07. 02. 2014, 00:27:35 »

Tak to je super, klient nedostal to co chtěl, aplikace z jeho pohledu vůbec nefunguje, ale stabilita stoupla . A teď si představte, že klientem Vaší aplikace nebude Franta Surfař, ale pilot letadla, který dostane hlášku 500 Internal Aircraft Error. Tady by je z Vašich aplikací trefil šlak http://www.faa.gov/, ale naštěstí by ty Vaše výtvory nepřošly certifikací.

Že tě to baví neustále trollovat. Považ, že na server chodí stovky až tisíce requestů za sekundu od zhruba stejného počtu userů. Takovej SIGSEGV nebo SIGABORT by nepotěšilo mnohem víc klientů, než jednoho s pětistovkou. Ale bohužel na světě je hodně takových jako jsi ty, co to nechápou

252

Vývoj / Re:C++ a výjimka v destruktoru

« kdy: 06. 02. 2014, 23:13:55 »

Já tedy zastávám názor, že výjimky obecně nejsou vhodné při snaze o vysokou odolnost proti chybám.

Naopak, stabilita mých aplikací výrazně stoupla, zejména serverů. Na každou vyhozenou výjimku někde čeká handler, který v nejhorším případě vrátí klientoví 500 Internal Server Error. Je to sice otrava (pro klienta), ale server se nesloží

253

Vývoj / Re:C++ a výjimka v destruktoru

« kdy: 06. 02. 2014, 18:03:21 »

V tom případě by měl destruktor autopilota vyhodit výjimku, že se nepodařilo nastavit původní stav, a případně tam přidat ty výjimky, co vyletěly. Něco jako dělá Java.

Dik, ted me napadlo, jak tohle realizovat v LightSpeed::Exception. Uz vim co narvat do vetve kdyz std::uncaught_exception je true. Podminkou akorat bude, ze vyjimka dedi std::exception

254

Vývoj / Re:C++ a výjimka v destruktoru

« kdy: 06. 02. 2014, 17:29:18 »

Pokud bude destruktor neco nastavovat, tak to je predevsim blbe navrzene.

S tím samozřejmně souhlasím a to vede na řešení:
Destruktor nedělá pokud možno nic sofistikovaného a ošetření chybových stavů patří mimo destruktor, z čehož vyplývá, že destruktor nevyhazuje výjimky .

Destruktor zejéma uklízí zdroje. A pokud se při úklidu zdrojů objeví chyba, tak za normálního běhu by měl o tom informovat výjimkou. Pokud se však objeví chyba při úklidu během stack unwind, tak taková výjimka už beztak nemá žádný smysl, protože bude z 99.9% souviset s již probíhajícím chybovým stavem.

Víc k tomu nemá co smysl psát. Myslím, že to je jasné a zřejmé. Jestli to děláte jinak, je to váš problém

255

Vývoj / Re:C++ a výjimka v destruktoru

« kdy: 06. 02. 2014, 14:57:21 »

Autopilot se normálně vypne třeba proto, že fouká silný nárazový vítr a nedokáže udržet letadlo v přímém letu. To je normální stav,

To ukazuje na chybné použití výjimky. Vadnou část jsem potrhnul.