Názory k článku Kylix (3) - OOP

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.

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!

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?

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* :)

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

No nevím, potom ale hrozí situace, kdy bude v programu chyba v kódu na opravu chyby a to se už potom dost blbě rozlejzá. Zásadní chyby se přeci odchytí zodpovědným testováním :-)

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

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)

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.

docela nechapu duvod portace takove aplikace na linux, kdyz mame top, ps a lsof.
ale nekdo ma mozna rad okynka.

Kylix byl Borlandy vyvinut proto, aby mohli udrzet ci rozsirit urcitou cast trhu, nebot existuje rada firem, vyvijejicich soft pro okna, ktere maji radu programatoru, kteri ovladaji pascal (delphi) a rady (tyto firmy - mozna) by se prosadily i v linuxu. Nemaji prostredky na sehnani novych lid, kteri by pro zakazniky dane aplikace napsali znova v C ci C++ na unixove platforme. Pro tyto firmy je jednodussi a levnejsi koupit kylix a prekompilovat stavajici zdrojaky pod linuxem (netvrdim, ze to je prochazka ruzovym sadem, ale za urcitych podminek to jde), ci novy vyvoj byl byl veden pro obe platformy.
Kylix nebyl vyvinut pro Open Source komunitu, takze myslim, ze veskera diskuze na tema "Prinos Kylixu pro budoucnost Linuxu" je zcela zbytecna. Borland chce (a je to jeho pravem) vydelavat penize a tudiz i mezi jeho pociny patri tyto veci.
A strna vyjimek - aplikaci napsanou v kylixu lze sestrelit pomoci kill, vyjimky slouzi k zachyceni neocekavane udalosti - ctu data z databaze a najednou spadne sit - mam na uzivatele vyblit neco jako ORA - 3110 ....
a nebo ho taktne upozornit, aby zavolal adminovi?

Videl jsem a slysel jsem uz hodne radoby ucebnic obektove oriantovaneho programovani, ale musim uznat, klobouk dolu, tahle se zadne nevyrovna, je naprosto nejohrsi, autora neznam, ale mozna byse mel nad tim, co pise, zamyslet, jestli mu to dava hlavu a patu, nebo jestli pise jen to, na co si vzpomene.
(a to budte radi, ze jsem nehodnotil, jestli se z tohoto nekdo dokaze naucit Object Pascal)

ProjevSe('Zvire',zvire);
ProjevSe('Pes',pes);

...kdyz uz pisete o OOP, nebylo by nazornejsi udelat ProjevSe jako metodu tridy Zvire a neucit zbytecne ctenare ne-objektovym manyrum?