Vlákno názorů k článku Kylix (3) - OOP od Dan Ohnesorg - Narosto zasadne nesouhlasim s tim, ze SIGSEV nema...
-
Dan Ohnesorg (neregistrovaný)
Narosto zasadne nesouhlasim s tim, ze SIGSEV nema vest k okamziteku ukonceni programu. To je proste naprosto zasadni chyba, kterou unixovy program nesmi udelat. A pokud ji udela, musi systemu umoznit, aby jej uklidil ze sceny. Z programu, ktere tohle osetruji, vyhazuji okna, ze se to bude resit a vzapeti havaruji z obsluzne rutine, protoze po SIGSEV netusi co vlastne maji v pameti mam hruzu.
-
Jan Svec (neregistrovaný)
Plne s tebou souhlasim.
SIGSEV znamena zasadni chybu programatora a nemel by se obchazet. Pak totiz kazde takovehle ukonceni by melo donutit uzivatele k vyplneni bugreportu a programatora k naprave chyby. Kylix a podobne nastroje ci systemy (hlavne jeden nejmenovany) takto podle meho nazoru (no-flame please) vychovava zvlastni kastu programatoru - ty, kteri se zenou za podporovanymi featurami a ne za tim, jak program pracuje a jak je navrzen. Sam z vlastni zkusenosti vim, ze tato cesta je snazsi, ale za jakou cenu. Programatori se stanou sobci, kteri by z kazdeho kousku kodu chteli vydelat miliony. A nakonec to dojde k utokum na GPL apod. Penize nejsou vsechno, pro programatora by melo byt vyzitkou ciste odvedeny program. Proc se treba Debian dlouhe mesice testuje nez se vypusti do sveta?
To vsechno je tema k zamysleni a jde jen o to, jak se programator rozhodne...
Howgh! -
autor (neregistrovaný)
To mohla byt pravda drive.
Vychazejme z toho, ze v kazdem programu JE chyba. Cilem prace programu je zpracovat DATA. Pokud je v programu chyba, data MUSI zustat konzistentni, at uz se stane s programem cokoliv. Programator musi mit moznost ROZHODNUTI, zda posle program do kytek, nebo se pokusi situaci vyresit-dulezita je ale ta svoboda! Vase reseni mi tu svobodu nedava.
Ja sam mam radsi programy, ktere mi reknou, ze je v programu chyba (jsme lide), nez ty, ktere hned sebou lisknou (jako skupina programu zacinajich na K*, ktere jsou vzorem pro robustni reseni a od jejichz pouzivani jsem v podstate upustil, protoze jsem se bal nekam kliknout, aby program nesel do kytek).
Mimochodem ten bugreport se tim nevylucuje a popremyslejme: ktereho programu uzivatel ten bugreport spise napise? -
Jan Svec (neregistrovaný)
Existuje nekolik pohledu na vec. Na unixech je obvykle bezpodminecne ukonceni programu. Ve win zase hlaska o chybe. Neberu nikomu jeho svobodu, ale zde jde spise o svobodu programu. A zadny program si nemuze delat co chce a pokud se o to pokusi, musi ho stihout trest (kill).
PS: Programy K* take nepouzivam, me vice sednou ty g* :) -
autor (neregistrovaný)
Proc je to obvykle? Protoze nebyly prostredky, pro dostatecne prehledne strukturovane odchyceni chyb. Vetsinou se to v unixu, pokud se nepletu, realizovalo ovladacem na globalni urovni. To je pak tezke urcit v ktere casti programu chyba vznikla.
Vyjimky umoznuji postupne odchytavat ruzne chyby na ruznych mistech - az pokud chybu neocekavame je odchycena az hlavni obsluhou a pak se muzeme (podle jejiho TYPU) rozhodnout co podniknout (save, exit(+zadost o bugreport:), nebo jen msg). Ale jak rikate je to veci nazoru a nikdo Vam moznosti ukonceni nebere:) -
tz (neregistrovaný)
Mam dojem, ze autor mysli pod slovem chyba neco jineho nez zbytek (pro-segfault) diskutujicich.
Jedna vec jsou ocekavane chyby, ktere vzniknou napr. pokud nelze otevrit soubor, neni k dispozici nejaky prostredek a pod. Takoveto chyby (=neprilis caste nestastne udalosti nezavinene programem) ma smysl odchytavat vyjimkami. Tyto chyby ovsem neprodukuji sigsev, krome pripadu kdy jsou spatne necekany a osetreny; a osetreni v tomto pripade muze byt jak vyjimka tak standartni test hodnoty kazde vracene funkce, a lze se bavit o vyhodach jednoho ci druheho.
Druha vec jsou chyby programu samotneho; typickym prikladem jsou spatne meze cyklu ci uziti neinicializovaneho pointru; typickym *projevem* je sahani do pameti kam nema. Toto jsou bezne chyby produkujici sigsegv, a nema cenu je maskovat - proste je spatne kus kodu, a je potreba to co nejdriv zjistit a opravit. A v tomhle pripade JE potreba segfault (u peclivejsich treba i sigabort), a clovek chce aby mu to spadlo presne na miste kde se to stalo.
Abych to vyjadril mene zmatene: vyjimky v C++ nejsou IMHO k odchytavani chyb programu, ale spatneho stavu okoli. -
autor (neregistrovaný)
To jsem tim nemyslel. Mojim cilem je napsat robustni aplikaci. Pokud jsem tam udelal nekde chybu - treba jsem zapomnel vytvoril konstruktorem objekt pro tisk, tak aplikace nema co padat. Proste se akorat nebude dat tisknout, uzivatel posle bug report a ja to opravim. Ale pri pokusu o tisk to jen zarve, ale aplikace bude klidne fungovat dal. To je podle mne NEKRITICKA chyba v pristupu k pameti (nechapu proc by se mel ukoncit). Ale ja koncim.
-
Jan Kozusznik (neregistrovaný)
IMHO program, ktery je tak nekvalitne napsany, ze vyhazuje SIGSEGV nema u skutecneho uzivatele co delat. Pokud se ma odchytavat tento SIGNAl tak jen za ucelem zalogovani stavu systemu...Nemyslim, ze pokud by se SIGSEGV odchytil, ze to zachrani nejaka data. Muze, ale nemusi ba naopak muze se udelat jeste vice skody.
-
tz (neregistrovaný)
Vychazejme z toho, ze v kazdem programu JE chyba.
Souhlas. Pokud je chyba ignorovana a "opravena", pak program s 97,7% pravdepodobnosti spadne za cas nekde jinde nebo sesrotuje data - kazdopadne, zjistit puvodni misto "pruseru" je temer nemozne.
Pokud program spadne se sigsegv (a predtim rekneme ulozi data), lze zjistovat co a kde se stalo a chybu ODSTRANIT.
Programator pri praci v C *ma* k dispozici rozhodnuti co delat pri segv - muze si napsat vlastni handler, ktery zajisti konsistenci dat a az teprve potom posle program do kytek.
K invektivam na adresu K* programu - ja mam stejny pocit s Kylixem, akorat ze nespadne, ale zatuhne - a muze to byt mymi castmi kodu. Ja bych radsi, aby to spadlo tam kde ma, nejlepe s core dumpem a moznosti post-mortem analyzy. Umi to kylix? (otazka neni recnicka, vazne bych to rad vedel)
Pokud vazne chcete ignorovat SIGSEGV libovolneho programu, v jednom z nedavnych phracku byl navod na sdilenou knihovnu ktera toto zajisti. S varovanim nedelat na prodkcnich vecech. Nezkousel jsem, ale treba by se to autoru libilo.
http://www.phrack.org/show.php?p=58&a=3 -
autor (neregistrovaný)
ad to C) tech 97.7% je v C, ale Object Pascal je postaven trochu jinak (jsou tam urcite mechanismy, ktere umoznuji korekci chyb-souvisi to s filozofii objektoveho programovani).Jinak pokud vim tak C++ ma obsluhu vyjimek taky, ze je malo lidi pouziva je jina vec. Pripada mi to, ze jsem brnknul na strunu folkloru ;)
ad coredump) ted momentalne nemuzu rict presne, ale kdyz jsem se dival nedavno do zdrojaku RTL, tak jsem tam nasel promennou, ktera urcovala zda se budu generovat coredump (zkusil bych grepnout sysutils.pas, nebo system.pas, nekdo to tam fakt je i s komentarem) -
pet (neregistrovaný)
Kdysi davno, jeste v ere dosu, jsem delal s jednim nejmenovanym databazovym produktem (nebyla to Foxka :-). Aplikace nahlasila vnitrni chybu a dala mi vybrat - ukoncit nebo pokracovat. Chtel jsem zachranit data, tak jsem dal pokracovat. Pak jsem dal ulozit, disk zablikal a pocitac ztuhnul. Asi po dvou dnech - archivace toho, co zbylo na disku, nova instalace dosu a programu a prohlednuti toho, co jsme zaarchivovali - bylo jasno: prisel jsem o 3/4 dat, ktere na disku byly. No comment.
ČLÁNKY DO MAILU