php openlog() returns boolean

Fórumok

http://us.php.net/manual/en/function.openlog.php alapján az openlog() PHP-s implementációja igaz-hamis értékkel tér vissza:

bool openlog ( string $ident , int $option , int $facility )

ez gondolkodóba ejtett.
eddig azzal voltam, hogy a legtöbb alacsonyszintũ php függvény a C implementációra épül, kiváltképp, ha teljesen ugyanaz a neve, funkciója.
namost a C implementáció viod-dal tér vissza:

void openlog(const char *ident, int option, int facility);

ha a php ezt használja, honnan veszi a boolean értéket? valamit visszaellenõriz?
vagy csak azokon a rendszereken tud FALSE-zal vissztérni, ahol a C-s openlog támogatja? de ezt nem említik a php.net-en.

ha még tovább furdalja az oldalamat, felütöm a php forrását...

Hozzászólások

Például megteheti, hogy ellenőrzi a paramétereket, és FALSE-sal visszatér, ha nem jók.

A PHP hulladéksága ismert tény; de mit keres ez a kérdés a C/C++ fórumban? ;-)

Speciel az nem a PHP hibája, hogy az eredeti openlog-nak nincs visszatérési értéke... (Szerintem minden műveletnek kellene legyen egy siker/hiba(kód) szerű válasza, legalábbis az egészen triviálisakat kivéve... akármit is nevezünk annak... az openlog-ot például biztos nem)

azt en ertem, hogy egyiranyu protokoll, de ha masik oldalon nem ul senki aki nezi ezt az egyiranyu protokollt, az ertelemszeruen hibanak minosul.
Akar egyiranyu, akar nem, ket resztvevos, vagyis van mirol megallapitani hogy esetlegesen sikeres-e, vagy sem (az hogy utana az uzenetet amit atadtam, elnyeli, mar mas teszta)

Mit ersz vele? Te egy szolgaltatast akarsz igenybe venni, szamodra az az informacio, hogy ez sikerult-e vagy sem. A syslog protokoll viszont ezt nem definialja, tehat ha az altalad hasznalt openlog/syslog API neked egy hibakodot ad vissza, az annyit jelenthetne, hogy a log bejegyzes biztosan nem sikerult, vagy esetleg sikerult. Neked ez mindegy kellene, hogy legyen, mivel te nem akarod a szolgaltatast felugyelni, csak hasznalni. Ha errol viszont az adott protokoll nem ad informaciot, akkor a hibakodnak csak annyi informacio erteke van, hogy az adott API-t jol hasznalod-e vagy sem (pl. hibas parameterek stb). Ez viszont nem a syslog protokoll resze, igy nem is standardizalt ...

ertem en hogy a syslog protokol egyiranyu, de itt most az openlog-rol volt szo. annak azert erdemes lenne visszajeleznie, hogy maga a syslogolas elokeszitese sikeres volt-e (pl sikerult ahhoz a /dev/log socket-hez csatlakozni vagy sem), aztan hogy a tuloldalt valaki fogadja-e az mar nem a kuldo problemaja.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Egyreszt: a syslog protokoll alapvetoen nem megbizhato. Innentol tok folosleges, hogy a /dev/log socketbe nem tudsz irni vagy utana veszik el az uzenet. Ha feltetlenul vagysz erre (bar mint leirtam, teljesen ertelmetlen) akkor hasznald a libet amit belinkeltem. Maradt meg nyitva kerdes?

felre erted. A libc implementacio a szar, mivel nincs semmilyen visszateresi erteke (es errno -t sem allit). Vagyis akar sikerul neki, akar nem, arrol te nem tudsz. A PHP-s visszater true/false siker/sikertelen eseten. Vagyis most kiveteles esetben a php-s a nyero:)

Az, hogy a PHP-s fejlesztok zsenialisan mashogy csinalnak MIDNENT, mint a tobbiek.

Tegnap ezt a kis gyujtemenybol szemezgettem, hat egyszeruen zsenialis.
http://www.reddit.com/r/lolphp

Peldaul AST nelkuli parzer, ami egybol bytecode-ot general, a 0x0 parzolasa meg egyeb finomsagok.

Egyszeruen akik a PHP-t csinaljak, orult emberek.

a php is a glue filozofia (http://www.sitepoint.com/phps-creator-rasmus-lerdorf/)
altalaban a kulonbozo libeket mindig ugy huzzak be, hogy viszonylag vekony wrappereket csinalnak csak, megtartva az eredeti lib apijat.
mi akadalyoz meg teged abban hogy userlandbol implementalj masik apit ha nem tetszik a beepitett? (ugye php-ban mar amugy is megirtad, c-extben meg meg tudnad csinalni, max 1 ora helyett 2 alatt).

Tyrael

Nem a PHP fejlesztok ellen szoltam, csak az erveles hibassagara akartam ramutatni. Mint fentebb irtam, semeddig nem tartana megirni C-ben mert az egesz kb annyira bonyolult, mint egy faek, de nekem erre nincs igenyem, mivel eddig mindenhol megfelelt a userland implementacio is.

A kerdestol fuggetlenul szerintem jot tenne a PHP-nak, ha kicsit egysegesitenek az API-jat, de ez szerintem nem fog megtortenni.

Igen, szar. Szar szabvanyos. Azt, hogy rendszer- es programtervezeshez kozod nincs (legalabbis remelem rofl), folyamatosan bizonyitod, most az is latszik, hogy kodot olvasni sem tudsz:

A PHP-s visszater true/false siker/sikertelen eseten. Vagyis most kiveteles esetben a php-s a nyero

Ha ertened a kodot, akkor felfognad, hogy a wrapper arra a problemara ad megoldast, amit sajat maga vezet be, ellenorzi a parametereket es mivel a zend_strndup()-on keresztul memoriat is foglal, azt is ellenorzi. Utana csak meghivja az openlog()-ot es arrol mar nem ad vissza hibakodot, te zseni!

Pedig igaza van. Nem arrol van szo, hogy a php-s openlog nem returnoli azt, amit a C API visszaad (semmit), hanem arrol, hogy a C API lehetne sokkal gondosabban is megirva. Regen nem a PHP szapulasa megy a szalban, akkor sem, ha egyesek csak erre kaptak fel a fejuket.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

parancsolj:

rc= openlog (...);
if (rc) {
    fprintf (stderr, "programnév.rutinnév.%d: *** openlog error %d errno=%d: %s\n",
        __LINENO__,
        rc, errno, strerror (errno));
    exit (32);
};

És, mit tesz isten, nem a végfelhasználó veszi észre, hogy a programozó rosszul paraméterezte a függvényt, hanem a tesztelő, ezzel megspórolva nem csekély pénzt és időt.

Nem ötlet kérdése, el kell dönteni, hogy mi a policy. Pl. lehet az a koncepció, hogy a fejlesztés/tesztelés/portolás során kétes esetekben érdemesebb megállni, hogy gyorsabban kijöjjenek a programhibák/platform-specifikus gondok; ezzel szemben az éles futás során esetleg akkor is továbbmegyünk, ha a tisztességesebb lenne megállni... pl a PHP is két ini-fájlt hoz magával, egy 'szigorúbbat' fejlesztéshez, és egy 'lazábbat' éles futáshoz.

Akkor probaljuk meg ujra, kedves "Nehez ezt felfogni?".
Hiaba datagramm socket, hiaba nem a protokoll resze (ami a kapcsolat felepitesenek szempontjabol nem jelent semmit), az open, illetve a send sikeressegerol kapsz informaciokat:
c-ben, legegyszerubb modja egy datagramm socket nyitasanak ez: socket = socket(...), utana kuldes szintjen write(...).
Ez a leheto legfapadosabb megoldas, ennel az openlog nyilvan valami szofisztikaltabb modon esik neki.
Nezzuk csak, mi az ami megakadalyozhatja a socket-et abban, hogy azt tegye, amit kerunk tole, es ezek csak rendszer szintjen, van meg egy jopar:
- NOT_ENOUGH_MEMORY -> Nem ittal elegendot ahhoz, hogy lepisalj az erkelyrol
- IOP -> sorban allas van ahhoz hogy lepisalj az erkelyrol
- IOI -> igaz lepisaltal, de magad ala sikerult, szoval biztos hogy nem hagyta el az erkelyedet de majd idovel talan lecsorog
- EACCESS -> valaki megakadalyozott abban, hogy lepisalj az erkelyrol
- EMFILE -> tul sokan pisaltok egy erkelyre
- SYSCALLFAILURE -> nem mukodik a vesed, ezert eselyed sincs lepisalni az erkelyrol
- EMSGSIZE -> tul sokat probaltal meg egyben pisalni az erkelyrol

Vagyis tortenhet kb 1000 dolog mikozben probalsz lepisalni az erkelyrol, ezzel szemben te openlog modjara szembeszelben is megprobalod.

Szoval nehez, latom ...

Most mondok valami sokkolot. Nincs socket, nincs UDP datagramm. Az mar az implementacio resze. A kuldo szamara van egy Service Access Point egy nem megbizhato atvitelt nyujto protokoll reteghez. Ez megvan? Vagy ismeteljem? OK, akkor menjunk tovabb ... Itt vagy mar? Jo, varok. ... Semmi gond, a lenyeg, hogy megertsd. Tehat, mivel a szolgaltatas nem megbizhato, az egvilagon semmi ertelme nincs a szolgaltatas igenybevevojenek egy "al-nyugtat" visszaadni. De legyunk egy kicsit konkretabbak es vegyuk a syslog-ot, mint peldat. Egy jobb sorsu syslog bejegyzes kb. ilyen utat tehet meg (van tobb lehetoseg is, de maradjunk most ennel): Originator/Device-->Relay 1-->...Relay N-->Collector

Neked az a velemenyed, hogy ha az elso lepes sikerult, akkor minden rendben van. Nagy hiba! Es ha az alkalmazasod barmifele modon is felhasznalja az adott implementaciotol (legyen az PHP, vagy egyeb mas szutyok) igy visszakapott informaciot, akkor az alkalmazas el van qrva! Nem kicsit, nagyon! Ugyanis ha neked feltetlenul szukseged van egy _megbizhato_ nyugtara, akkor arra vannak olyan megoldasok, ahol az atvitel is megbizhato, ha viszont a nyugta, nem is igazi nyugta, akkor mi a fenenek kell?

Ha ezt sikerult felfogni, amit az elozmenyek ismereteben erosen ketlek, akkor azt is megerted, hogy mekkora faszsagokat hordtal itt ossze a kis listaddal. Egyebkent felelmetes mennyire nincs absztrakcios keszseged, eleg ha mar a legelso peldadat vesszuk: NOT_ENOUGH_MEMORY -> Nem ittal elegendot ahhoz, hogy lepisalj az erkelyrol
A pisad maga a payload, ha nincs, mit akarsz a SAP-on keresztul igenybe venni? Mi koze van ennek a szolgaltatashoz? De a tobbi legalabb ugyanilyen baromsag ...

Ha nincs socket es nincs udp datagramm (bar ez utobbit peldakent hoztam csak), akkor ez mi?
misc/syslog.c:
LogFile = __socket(AF_UNIX, LogType | SOCK_CLOEXEC, 0);
Neezzdd maaaa mieezzzzz, csak nem egy socket? Es erdekes, valamit ellenoriz is utana: csak nem a LogFile valtozot es az errno-t?
Ahh ugyan, ez nem lehet, mert ilyet nem tehet, mert hat Originator/Device-->Relay 1-->...Relay N-->Collector
Jah bazdmeg, csak egy szimpla socketen, ami visszaterhet hibaval.
Ha valami visszaterhet hibaval es azt valaki elnyeli, az szerintem nem normalis.
De mivel nem tudsz olvasni (es nem nyugtazast irtam, hanem a kuldes modjat, de ezt neked mint egbolpottyant felisten tudnod kene olvasas nelkul is).
Szoval osszegezzuk: hasznal socketet? Igen! Visszaterhet a socket hibaval? Igen! Mit csinal az openlog? Elnyeli (pontosabban magaban ellenorzi hogy sikerult-e, aztan meg nekiesik parszor biztos ami biztos egy while (retry < 2) mellett (hardcode magic numbers rulz)).

Szoval ha mar josz azzal a szep osi-val, akkor nezz utana, mert nem eleg csak a legfelso retegeket (ergo szo szerint feluletesen:D) ismerni.

azert vagyok hulye, mert nem tartom normalisnak a letezo hibauzenetek elnyeleset? Ezt normalis esetben egy code review alkalmaval visszadobjak, hogy gondoljam ujra (magic numbers, connection retry specifikus metodus eseten (ez mar kesz vicc), hibauzenet elnyelese). Ertem en hogy nem megbizhato a kapcsolat, de tudjak mar rola hogy az eselyek 0%-ra estek

abban igazad van, hogy vannak detektalhato hibak a folyamatban.
ami szerintem vitathato (es szerintem ezen megy a vita igazabol), hogy biztos hogy jo otlet lenne-e bevezetni a libc fuggvenyhivasba visszateresi erteket/hibakodot, hogy a sikeres esetben sem garantalhato a logolas megtortente.
ertem en, hogy azt mondod hogy csak a detektalhato hibak reportolasara szannad, de sokkal nehezebb lenne kommunikalni a hivo fel fele, hogy nem true/false a visszateresi ertek, hanem maybe/false.

szoval szerintem nem olyan egyertelmuen rossz a mostani libc implementacio.

Tyrael

Ez egy olyan döntés, amit valakik évekkel ezelőtt meghoztak, most már nincs mit csinálni vele, csak bosszankodni...

Egy közismertebb probléma pl. a fgets visszatérési értéke: minden szempontból előnyösebb lenne, ha siker esetén hosszat adna vissza -- de nem azt ad, és ezen már visszamenőleg nem lehet változtatni, legfeljebb mást használni helyette.

"szoval szerintem nem olyan egyertelmuen rossz a mostani libc implementacio."
Sajnos ahogy mar felettem irtak, inkabb historikus okai vannak ennek. Persze, jol mukodik, sot, probaljak toldozni (a retry-k erre utalnak), ennek ellenere valamikor nagyon regen valaki igen szarul talalta ezt ki

Ha ez visszaadna egy hibát az ilyen esetekben, akkor tudnád, hogy biztos NEM sikerült logba írni, ez tény. De ha nem ad vissza hibát, az még NEM jelenti azt, hogy biztos sikerült logba írni. Ez egy hamis biztonságérzetet adna, mert csak a szóba jöhető hibák nagyon kis részét fedi le. A visszatérési értéknek KB. semmi köze nem lenne ahhoz, hogy valóban diszkre került-e a logolandó üzenet valahol. Akkor meg minek visszaadni bármit is.

BTW fentebb én is benéztem ugyanezt, azt gondoltam, hogy miért is ne adhatna vissza hibát audit okból pl. Csak én beláttam a tévedésem :). Igoornak igaza van, nagyon is számít, hogy a csatorna további része nem megbízható, és azt úgysem lehetne detektálni.

--

> Ez egy hamis biztonságérzetet adna

Azt kellene megérteni, hogy a libc nem a programozó pszihoterapeutája, hanem egy munkaeszköze -- semmi szükség rá, hogy 'pedagógiai célzattal' megsemmisítsen egy információt. Ha abból indulunk ki, hogy a programozó hülye, akit védeni kell önmagától (vö: 'hamis biztonságérzet'), akkor az miért nem jut eszünkbe, hogy ugyanaz a hülye programozó el is ronthatta a syslog fv paramétereit, amiről udvarias gesztus lenne tájékoztatni a hülyéjét.

Mit szólnál ahhoz, ha a villanyszerelőnek szigeteletlen szerszámmal kellene dolgoznia, azzal a magyarázattal, hogy 'a munkád amúgy is veszélyes, ez a kis műanyagréteg csak hamis biztonságérzetet adna!'

"Mit szólnál ahhoz, ha a villanyszerelőnek szigeteletlen szerszámmal kellene dolgoznia, azzal a magyarázattal, hogy 'a munkád amúgy is veszélyes, ez a kis műanyagréteg csak hamis biztonságérzetet adna!'"
Azt rakjuk hozza meg: Mindezt ugy, hogy nem kapsz szerszamot hogy ellenorizd, feszultseg alatt van-e. Nyald meg, vagy bejon/vagy nem

nem jo a pelda.
a jo pelda az lenne, hogy adnal-e a villanyszerelonek olyan csavarhuzo+fazisceruzat, ami csak akkor vilagit ha van feszultseg a mert vezeteken, de neha olyankor sem vilagit, amikor a vezetek feszultseg alatt van.
akkor mar inkabb csak csavarhuzot adok neki, es ha megis megbizhato fazisceruzara van szuksege, akkor azt fogja hasznalni, ahelyett, hogy a megbizhatatlan eszkozre tamaszkodva aramutest szenved.

errol szol a tortenet.

Tyrael

De ha egyiranyu (simplex) a protokoll, akkor hiaba ul ott a fogado oldalon valaki, nem tud szolni a kuldonek, hogy sikerult-e a muvelet. Pont azert, mert a csatorna egyiranyu.
Ehhez duplex csatorna kell, es legalabb half-duplex protokoll.

Termeszetesen a megbizhatatlan duplex csatorna sem megoldas, lasd a ket hadsereg problemat.

dgram-ban is kaphatsz hibauzenetet. Az hogy a kommunikacio sikeressegerol nem kapsz visszajelzest mert datagram socket-en keresztul zajlik az mar egy masik kerdes. A socket megnyitasakor (openlog) es a kuldes pillanaataban is tortenhet barmi (oom, mof, stb.)

Szerintem ezen brillians meglatasodat azonnal tovabbitsd a Mcsiv NevemTeve Hrgy84 Engineering Task Force neveben a The Open Group cimere mondjuk a "Light up the darkness" mottoval, mert ok meg mindig ugy gondoljak, hogy "The closelog(), openlog(), and syslog() functions shall not return a value". Leforditsam, vagy ez legalabb menni fog? Ha esetleg megis problemad lenne a "shall not" ertelmezesevel, segit a megfelelo RFC. Vegulis ez a helyes hozzaallas, vesszenek a szabvanyok! omfg

Alapvetően a következő két állítás áll szemben egymással:
1. Ne adjunk vissza hiba/siker információt, mert a 'siker' azt sugallná a hívónak, hogy garantáltan megtörténik a logolás, ami nem igaz.
2. Adjunk vissza hiba/siker információt, mert a 'hiba' legalább tájékoztatja a hívót, hogy garantáltan nem történik meg a logolás.

Namostan ha flexibilisen akarsz működni, akkor azért érdemes a másodikat választani, mert egy return value-t bármikor ignorálhatsz, de egy megsemmisített információt már nem tudsz visszaállítani.

a szabvany a protokollt es a mukodest definialja, nem azt hogy egy rendszerszintu hivas sikeresseget/sikertelenseget szo szerint eldugsz. Az RFC pedig csak a kommunikaciora vonatkozik, nem az implementaciora. Ezt valakinek vagy sikerul megertenie, vagy nem, neked nem sikerult, sot mindenki hulye aki azt mondja, hogy szar az implementacio. (legalabb ez utobbi ket fogalomnak googlizz utana, hatha vegre leesik).
Csak viszonyitas keppen: van normalisan mukodo es normalisan lefejlesztett implementacio is:)

minden bizonyara igy van, viszont a kerdesekre nem valaszolsz, ertelmes hozzaszolasod nincs ami alatamasztana azt amit allitasz (hogy miert jo az hogy rendszer hivasok hibauzeneteit nyeljuk el, aminek koze nincs a protokoll/szabvany/rfc reszhez). Emellett azt probalod bizonygatni hogy en vagyok a hulye, hogy sehol nincs socket (mikozben van), hogy nem lehet out of memory (mikozben lehet).

Igen, ez csak egyet bizonyit:)

Az megvan, hogy a datagram szabvanya valojaban nem mond semmit a socket megnyito fuggveny visszteresi ertekerol? Sot, azt sem mondja, hogy _kell_ megnyito fuggveny, meg azt sem, hogy parametereinek kell lennie. A datagram RFC-jenek koze nincs ahhoz, amirol itt beszelgetunk. Az egyik a szabvany a masik pedig egy annyira implementaciokozeli reszlet, amivel a szabvany egyszeruen nem foglalkozik
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Ha a kepessegeid az elvarhato szinten lennenek, akkor kb. 1 perces megfeszitettnek kozel sem nevezheto munkaval megszerezhetted volna az ahitott informaciot:

The Open Group cimere ..., mert ok meg mindig ugy gondoljak, hogy "The closelog(), openlog(), and syslog() functions shall not return a value"
Hmm, google? the open group? syslog?

Ha esetleg megis problemad lenne a "shall not" ertelmezesevel, segit a megfelelo RFC
Hmm, google? rfc? key words?

Huha, egeszen beleizzadtam. Na jo, a masodik kicsit trukkos, ott erteni kellett volna, hogy az RFC-re hivatkozas, a "shall not" ertelmezesere utal ...

Nem tudom milyen implementaciorol beszelsz, de ez biztosan azert van, mert ahogy korabban mar irtad, szemben veled, en nem ertem a kerdeses "idegenszavak tokeletes mivoltat". Ha a The Open Group honlapjan fellelheto standardrol beszelsz, amirol azt gondolod, hogy nem mas, mint az azt implementalo GNU C Library leirasa, akkor jozan eszemre tamaszkodva azt mondanam, hogy tevedsz, de nem mondom, mert minek? Kit erdekel ez? Eddig se erdekelt rajtam kivul szinte senkit. Probaltam mar korabban eloszor normalisan elmondani, hogy a syslog egy nem megbizhato adatatvitelt nyujto protokoll (egyebkent RFC-t _erre_ vonatkozoan szerintem nem is emlitettem, bar lehet, hogy tevedek) es hogy a The Open Group a vonatkozo standardjat ennek megfeleloen hozta letre es ha valakinek az utobbinak megfelelo libc-s implementacioval problemaja van, akkor elsosorban a The Open Group-hoz forduljon, mert ok specifikaltak az adott szabvanyt. Mindezt elmondtam korabban, de mint altalaban, megint ment a szakertes. Ennyi, ezt en jobban mar nem kivanom ragozni. Aki felfogta felfogta, aki nem, az meg nem.

Akkor kis fejtagitas, mert ugy nezem mindenki elkezdett a sajat malmaban orolni.

- Felmerult, hogy az openlog miert nem ad vissza hibat
- Erre az lett a valasz, hogy a datagram simplex protokoll
- Mcsiv jelezte, hogy ennek nem kell a protokoll reszenek lennie, maga az openlog ettol meg adhatna vissza hibakodot
- Itt kezdodott a hosszu vita arrol, hogy az openlog mier NE adjon vissza hibakodot, ha sikertelen volt a log megnyitasa
- Ennek reszekent te elkezdtel egy - kozelebbrol meg nem nevezett - szabvanyra hivatkozni. Mivel egeszen a te kommentedig a datagram protokollrol, mint olyanrol volt szo, az pedig - meglepo modon - nem specifikalja, hogy az ot implementalo fuggvenyek adnak-e vissza hibauzenetet/hibakodot/barmiegyebet, igy ertelmetlenne valt az, amit mondasz.

Valoszinusitem, hogy te a POSIX standardra gondolsz "szabvany" cimszo alatt, vagy valami nagyon hasonlo programozasi felulet szabvanyra, azonban a topicban senki nem emlitett ilyen szabvanyokat, a legelso hivatkozas a datagram protokoll szabvanyara tortent.

Szoval, szepen megkerlek, definiald, hogy TE valojaban nev szerint melyik szabvanyra gondolsz, mert szerintem itt mindenki felreertesben van.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

En ugyan pontosan leirtam mar egyszer es ha tenyleg meg akarnad erteni, akkor eleg lenne figyelmesen elolvasnod, amit eddig idevestem NevemTeve "Speciel az nem a PHP hibája, hogy az eredeti openlog-nak nincs visszatérési értéke..." felvetese utan. De ha ez tul hosszunak es megeroltetonek bizonyulna, akkor ott van az osszefoglalo, amire eppen valaszoltal, abban is pontosan benne van, mirol beszelek es hol talalod a megfelelo informaciot. Talan elvarhato lenne, hogy ne kelljen belinkelni az oldalt, mivel ha csak bemasolnad kedvenc keresodbe azt a par kulcsszot, amit naiv modon odapotyogtem, kb. az elso talalat lenne. Gondoltam ez a feladat Mcsiv kepessegeit sem haladja meg, de hat kenytelen vagyok belatni a tevedesemet.

De nem banom, megegyszer utoljara. Tagoltan ... tagoltabban ;)

Az elso amirol irtam, maga a Syslog protokoll, aminek leirasat a megfelelo RFC5424-ben talalod meg. Ez az ajanlas nem ir semmit a transzport retegrol, amit ti folyamatosan idekevertek a socket es UDP szavakat skandalva. Ebbol az RFC-bol alapvetoen ennyi informacio erdekes jelenleg szamunkra (persze el lehet olvasni az egeszet ;):

The syslog protocol does not provide acknowledgment of message
delivery. Though some transports may provide status information,
conceptually, syslog is a pure simplex communications protocol.

Innentol kezdve vilagos kellene legyen, hogy badarsag lenne egy nyugtat varni, foleg ha elolvassuk a kovetkezo RFC-t is, ami a hagyomanyos modon UDP-n alapulo kommunikaciot irja le. Az ott leirtak elolvasasa utan, meg inkabb ertlemetlenne valik a megbizhato nyugta utani sovargasotok.

Ez lett volna az elso lepes, amit meg kellett volna tennetek, de hat korabban nem sikerult, remelhetoleg ezuttal igen. De lepjuk meg a kovetkezo lepest.

Az RFC 5424-nek megfeleloen a The Open Group is letrehozta szabvanyat a C-s implementacioknak utmutataskent. Tortenetunk csokkentertelmu hose, Mcsiv, ezt a _szabvanyt_ emlegeti tevesen implementaciokent, hiszen sajat bevallasa szerint o tisztaban van a fogalmakkal. Hat nincs, de psssszt! Nem kell neki megmondani, vessunk inkabb az emlitett szabvanyra egy pillantast:

The syslog() function shall send a message to an implementation-defined logging facility, which may log it in an implementation-defined system log, write it to the system console, forward it to a list of users, or forward it to the logging facility on another host over the network.

Nocsak, ebbol is latszik, hogy nem egy bizonyos implementaciorol szol a fenti leiras, hiszen a transzport reteg tovabbra sincs definialva es meg veletlenul sincsennek emlitve az UDP, datagramm ill. socket szavak. A kovetkezo info is erdekes, bar mar ezt is irtam:

It is not necessary to call openlog() prior to calling syslog().

Es most jojjon a lenyeg:

The closelog(), openlog(), and syslog() functions shall not return a value.

Deja vu? Igen, ezt a mondatot mar pontosan ideztem korabban is, megjelolve azt is, ki felelos erte :p Es meg indirekt mankot is nyujtottam arra az esetre, ha a "shall not" ertelmezese gondot jelentene, hiszen az ember sosem lehet biztos benne, milyen melysegben asta bele magat a hallgatosaga az angol nyelvtanba.

Nofene, ez meg hogy? Hat ugy, hogy mivel nincs garancia az atvitelre es annak modja sem ismert, abszolut baromsag hibakodot rendelni a syslog() hivasahoz. En tenyleg nem vagom, ennek megertese miert okoz ill. okozott gondot, de valoszinuleg en es a fenti szabvanyok alkotoi vagyunk hulyek es az egesz szar, ugy ahogy van, hiszen megmondtak a HUP-on!

Na mindegy, ez eddig megvan? Es akkor most jojjon a vesszoparipatok a fenti szabvany manifesztaciojakent, igen, a GNU C Library. Ez a lib a The Open Group szabvanynak megfeleloen implementalja az adott fuggvenyeket, ennek megfeleloen nem ad vissza hibakodot. Igen, van socket hivas, de nincs hibakod, mivel az mar implementacios reszlet, amit a szabvany szerint el kell rejteni. A syslog() hivojanak szempontjabol egy lehetne a lenyeg, hogy a log bejegyzes sikerult-e, vagy sem. Mivel erre nem lehet megbizhato valaszt adni, nincs is valasz. Ha megbizhato atvitelre van szukseg, arra is vannak szabvanyok, amire itt rugoztok, az nem az. Ennyit kellett volna megerteni.

Egyebkent szamomra tovabbra is egy talany, miert kellett ezt az egeszet immaron harmadszor, ezuttal szajbaragosan itt leirnom. Elvarhato lenne, hogy kulcsszavak alapjan is rakeressen az, akit erdekel. Akit meg nem erdekel, az minek bofog bele?

De van meg valami, ami elborzaszt. Az, hogy a Hungarian Unix Portal-on lovese sincs a regisztraltak egy (omg, nagy?!) reszenek, mi az a The Open Group. Wow!

Reszemrol ennyi, en ehhez mar mast nem akarok hozzafuzni, aki Mcsiv mellett meg most sem erti, az kesobb sem fogja ...

Oke, akkor lassuk, hogy en mit mondtam (pontosabban kicsit kifejtve):
- A syslog protokoll szabvanya (ezek szerint az RFC 5424) nem mond semmit, hogy kell vagy nem kell visszeterni az ot implementalo fuggvenynek barmivel. Mas megfogalmazasban: megengedi, hogy amennyiben hiba tortent akar az uzenet atvetele, akar a kezbesitese soran, ez az uzenet feladojanak nem specifikalt formaban visszajelzesre keruljon, azzal a kivetellel, hogy ez nem tortenhet a protokoll keretei kozt - hiszen a Syslog egy simplex protokoll.
- Az Open Group mar ennel egy picit restrictivebb volt, o azt mondja, hogy nem terhet vissza ertekkel. Ezt elfogadom - bar hibas dontesnek tartom -, azonban itt hivnam fel a figyelmet, hogy C-ben nem csak visszateresi ertekkel lehet hibat jelezni.

Szerintem ott hibazik az ervelesed, hogy azt mondod: az implementacios reszletek soran keletkezo hibat el kell rejteni. A Syslog szabvany csak annyit mond: a protokoll nem nyujt lehetoseget a keletkezo hibak jelzesere, az Open Group szabvany pedig csak annyit: az adott fuggvenyeknek nincs visszateresi ertekuk. Ezek egyike sem jelenti implicite azt, hogy a hibak elrejtendoek. Es ez iszonyu nagy kulonbseg.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

"The closelog(), openlog(), and syslog() functions shall not return a value"

"az Open Group szabvany pedig csak annyit: az adott fuggvenyeknek nincs visszateresi ertekuk"

Meg kellene tanulni angolul rendesen, de mivel gyanitottam, hogy gondok lesznek, ezert linkeltem be fent a megfelelo RFC-t (2119) is, ahol megtalaltad volna a kovetkezo bejegyzest:

MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.

Tobbet nem tudok erted tenni, sajnalom.

Mindkettotoknek: igazatok van. Azonban az Open Group-fele szabvany egyertelmuen kimondja, hogy az adott fuggvenyeknek nem lehet visszateresi ertekuk. Ilyenkor csak az errno, vagy valamilyen mas kozos globalis valtozo marad a hiba jelzesere - mindenesetre, abban megegyezhetunk, hogy ha nagyon akarnak, akkor _volna_ mod a hibak jelzesere.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Most olvastam ugyanebben a topikban:

> Ha errol viszont az adott protokoll nem ad informaciot, akkor a hibakodnak csak annyi informacio erteke van, hogy az adott API-t jol hasznalod-e vagy sem (pl. hibas parameterek stb). Ez viszont nem a syslog protokoll resze, igy nem is standardizalt...

Akkor melyik álláspontod a hivatalos? Nem szabad jelezni a lokálisan detektált hibát, mert meg kell felelni a szabványnak, vagy ez nem is része a szabványnak?

Nem ertem a problemat. Ugy kell erteni, ahogy irtam. A visszateresi ertek, amit pl. a PHP-s implementacio visszaad, nem standardizalt. Egyszeruen vizsgalja az elofelteteleket, majd ha azok teljesultek, meghivja az openlog()-ot, amitol meg nem kapsz vissza semmit, mert azt meg a specifikacio igy irja le. Az, hogy te a wrappertol kapsz egy true-t vagy false-t, semmit nem jelent a syslog-ra, mint szolgaltatasra vonatkozoan, ennek megfeleloen is kell kezelned. Ennyi.

Nem igazán tudtam eldönteni, hol kapcsolódjak be a flamebe, úgyhogy majd itt.

Senki nem mondta, hogy tilos hibakódot visszaadni. Csak nem célszerű. Még a glibc implementáció esetén sem tud az openlog minden lehetséges hibát detektálni, ezért hiába is ellenőrzöd, hogy a függvény mit adott vissza, siker visszatérési érték esetén sem lehetsz biztos benne, hogy a futása valóban sikeres volt. De mi van akkor, ha egy másik libc implementáció egyáltalán nem tudna semmilyen hibát detektálni? Azaz annak openlog implementációja mindig siker visszatérési értéket adna, miközben adott esetben hiba történt a futása során. A hibakezelésed dead code lenne, a fordító akár ki is optimalizálhatná.

Amikor megtervezték az openlog függvényt, nem tervezhettek arra, hogy egy konkrét implementáció tud-e majd hibát detektálni, vagy sem. Emiatt teljesen ésszerű, hogy azt mondák, hogy akkor egyik implementáció se adjon vissza semmit, hiszen annak nincs értelme, hogy bizonyos implementációk teljesen feleslegesen adjanak vissza egy konstans visszatérési értéket. Így legalább fejlesztéskor sem ér meglepetés, mert nem fog előfordulni, hogy a függvény rendben lefut, mégsem sikerül a logba írni.

use the source luke: hibas parameterek eseten false, amugy meg true.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

A PHP-s openlog()-gal nagyon sok baj van, pl. az Apache hibalogot is átirányítja, ha mod_php-t futtatsz, nem tudsz különböző application nevekkel logolni, stb. Éppen ezért mi annó PHP-ban implementáltuk a syslog működést, a syslog függvényeket kihagyva: GitHub

Elég sokat teszteltük, élesben is megy és eddig nem volt baj vele. Nézd meg, érdekes lehet.

vagy csak siman openlog es valami egyedi identet valasztasz
aztan syslog(LOG_XY, "fakeident AZuzenet")

es syslogba felveszel ra filtert, meg igeny eseten tovabbkuldesre templatet, es utana tovabb mar ugy megy, hogy fakeident lesz a real ident es uzenet is jo lesz.

Ma esti utolsó (illetve már tegnap esti): tkp az az állítás, hogy a visszaadott érték hiánya azoknak kedvez, akik túl buták ahhoz, hogy figyelmesen elolvassák a leírást, hogy mit is jelent(ene) a visszaadott érték, ehelyett saját butaságukban jutnának téves következtetésre. Namostan ezzel az elmélettel számos gond van, az egyik rögtön az, hogy a C és a Unix célközönsége nem az a réteg, aki nem képes figyelmesen elolvasni egy leírást. De komolyan. A C+Unix belépő feltétele a 120-as IQ meg az Asperger szindróma.

Hát jobb is lesz lezárni. Kb háromszázszor írtam le eddig, hogy információt megsemmisíteni rossz ötlet, és ezt azzal indokolni, hogy ezzel a tudatlan programozókat védjük önmaguktól még rosszabb ötlet. EOF.

Rosszul állsz hozzá, nézd egy kicsit távolabbról. A jelenlegi syslog API létezik, sok év óta ilyen, és még sok évig ugyanilyen lesz. A HUP-on vitázni róla nem túl értelmes dolog. Páran próbálnak rá magyarázatot adni, értelmet keresni benne, hogy vajon miért van így. Lehet, hogy azért csinálták ilyenre, lehet, hogy nem, de legalább egy épkézláb lehetőség. Ebbe belekötni milyen dolog már? Az egy másik dolog, és kb. tök mindegy, hogy ez ki szerint jó, meg ki szerint rossz, mert most ez van és kész. Majd a következő syslog API working groupban lehet javaslatokat tenni :).

--

Olvass vissza: én is leírtam korábban, hogy ez már el van cs_szve, és pont. Mindazonáltal akár a jövőbe is pillanthatunk: az itt jelenlevők némelyike időről időre programokat tervez, és olyan döntéseket hoz, hogy 'itt egy információ, amire most éppen nincs szükségem, döntsek-e úgy, hogy soha senkinek sem lesz rá szüksége, tehát megsemmisítem'... egy ilyen döntésben esetleg segít, ha több álláspontot ismer az ember, mielőtt dönt.

Off: Hirtelen egy másik példa jutott eszembe: bizonyos kontextusokban (parciális kulcson való keresés) hasznos lenne, ha a bsearch visszaadná azt a helyet, ahol a keresett (de nem talált) elem helye lenne. Vagy hasznos lenne, ha az összehasonlító függvénynek lehetne ugynevezett user-paramétere. Természetesen a standard bsearch sosem volt megváltozni, de ha egyszer éppen tervezünk valami újat, akár ilyesmik is eszünkbe juthatnak.

> ez már el van cs_szve, és pont

Én inkábbb azt mondanám, hogy szélesebbb látókörrel lett megtervezve, mint ahogy te most nézed.

Ha csak azt nézed, hogy nem ad vissza hibakódot, akkor mondhatod hogy rossz. Ha azt is nézed, hogy az ideiglenesen szünetelő log-olás sehogy sem akadályozza az alkalmazások működését, a hiba megszünésekor magától helyreáll, üzenet lavina nem temeti maga alá a központi log szervert, stb., akkor meg jó.

Erre már válaszoltam (olvass vissza), de egyébként off-topik: azt csinál, amit akar... Ez nem olyan, mint az 'irányított demokrácia', ahol nem mondják el az igazságot az embereknek, mert azok a hatalom szerint nem elég érettek arra, hogy szembenézzenek az valósággal...
Azt is leírtam már párszor, hogy nem csap senki a kezedre, ha ignorálsz egy visszaaadott értéket, úgyhogy ez a 'nekem nem kell, tehát senkinek se kelljen' érvelés pláne nem jó: ha te még arra sem vagy kiváncsi, ha a programozó hibája miatt soha egyetlen üzenet sem jut el sehová, az legyen a te tiszteletre méltó magánügyed, de miért szívjanak mások is emiatt?

ha te még arra sem vagy kiváncsi, ha a programozó hibája miatt soha egyetlen üzenet sem jut el sehová, az legyen a te tiszteletre méltó magánügyed, de miért szívjanak mások is emiatt?
Ugye te nem ugy kezdesz el hasznalni egy API-t, hogy addig probalgatod a fuggvenyparametereket, amig OK-t nem kapsz vissza? Nyugtass meg, hogy nem! De meg nyugodtabb lennek, ha kiderulne, hogy egyaltalan nem irsz kodot. Ha meg tesztelni akarod a syslog() hivasaidat, mar leirtak, hogy van modja...

C-rol beszelunk, tehat true/false, es/vagy allitson be errno-t, mint az osszes tobbi ertelmes fuggveny. Es ha nincs is visszaterei erteke, a belso implementacio soran keletkezo hibakat akkor is kommunikalhatja az errno valtozoval.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

Ertem, brillians! Es akkor a te alkalmazasod, ami a sytem logba akar irni, anelkul, hogy tudna, hogy mi van a hivas mogott, meg socket sem kell, hogy legyen elvileg, lekezeli az osszes lehetoseget. Es mivel a hibakod nincs standardizalva, ezt lehetoleg minden rendszeren megteszi, amin majd futni fog, meg azon is, amirol fogalmad sincs, hogy hogyan implementalja a syslog szolgaltatast. Mindezt azert, hogy elmondhasd, hogy kaptal egy maybe-t egy nem megbizhato szolgaltatastol. Ez kezd egyre jobb lenni, mondanam, hogy elvezem, de ilyenkon valahogy mindig Ford Fairlane klasszikusa jut az eszembe: "enyhel szorakoztato, de leginkabb fajdalmas". Tudod mit, en nem akarok itt senkit, semmire megtanitani, nekem eleg, hogy en tudom mit csinalok es azt igen jol meg is fizetik. Reszemrol tenyleg ennyi ehhez a magas szinvonalu szakmai topikhoz.


syslog(...)
if(errno != 0) {
  // hiba tortent
}

Ez miert problemas? Az errno annyibol standardizalva van, hogy minden ami nem OK, az hiba. Nekem pedig nem azzal kell foglalkoznom, hogy MI tortent, hanem hogy TORTENT-E valami.

Sokszor mar a biztos negativ is segitseg. Az ember tobbfelekeppen tud logolni, tehat ha azt mondom, hogy ezen az uton biztosan NEM sikerult lerakni a logot, akkor legalabb eselyem van valasztani egy masik utat. Es ez meg mindig jobb, mint a "hat a franc se tudja" hozzaallas.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

A syslog azert jo, mert az akar tobbfele is szetkuldheto, standard formatumu - tehat akar adatbazisba is rakhato, akar szurheto is -, a backup megoldas meg altalaban valami fajl/konzol alapu alternativa lenne.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

En ugyan nem irtam, hogy a programozot kell vedeni, arrol meg nem tehet a vilag, hogy nem tudsz szabvanyokat ertelmezni es meg letezesuk ertelmere sem talasz magyarazatot, de mint fentebb irtam, ott van kihez kell panasszal fordulni, irj nekik es varj a valaszkent kapott elnezo mosolyra. Hiaba, te is majd csak a meg nem ertett zsenik koze tartozol, akiket nem emelt piedesztara a vilag. De nezd a jo oldalat, legalabb nem kuldtek maglyara sem ...

Nah, átolvastam a hozzászólásokat (az összeset), szóval akkor egy kis összegzésként ideírom az eddig elhangzottakat, felmerűlt kérdéseket és válaszokat.

A felmerülő probléma a következő volt:
- A syslog hívások (openlog és társai) elnyelik a hibaüzenetket.

Erre a tömör megoldás már párszor elhangzott, miszerint:
- Minek hibaüzenet? A hibaüzenet csak szar programot eredményez!
- A specifikáció ezt írja (The closelog(), openlog(), and syslog() functions shall not return a value.)
- A syslog egyirányű protokoll, nem tud visszaadni hibaüzenetet (mert nincs miről).

És a válaszok az előbbiekre:
"Minek hibaüzenet? A hibaüzenet csak szar programot eredményez!"
Érdekes érv, de gondoljunk arra, mi van ha pl nem figyeljük egy malloc hívás visszabüfizett eredményét (Segmentation fault), de erre még lehet példákat hozni. Szerintem nem megfelelő eredmény az, hogy ha elvárjuk egy programtól hogy log üzeneteket küldjön és 100% hogy képtelen rá, arra még csak egy figyelmeztetést sem tud adni (programtól függően akár le is állhatna, de ez policy kérdése).
"A specifikáció ezt írja (The closelog(), openlog(), and syslog() functions shall not return a value.)"
Ez így van és ezzel nincs is semmi probléma. Viszont csak egy erősen korlátolt/programozáshoz nem értő ember állítja azt, hogy csak egy mód van a hiba jelzésének, miszerint visszatérési értéke van egy metódusnak.
Pontosan erre van kitalálva az errno (The errno.h header file defines the integer variable errno, which is set by system calls and some library functions in the event of an error to indicate what went wrong.)
Innentől kezdve, a dolog ugyanúgy igaz marad a specifikációra, megfelel az errno beállításának követelményeire és az elfogadott programozás technikai szempontoknak (miszerint nem nyelünk el a program futás során fellépő hibaüzeneteket).
Mindezt annak figyelembevételével, hogy ezek a sokat emlegetett specifikációk és RFC-k sehol nem definiálják ezt, miszerint nem szabad hibajelzést adni.
"A syslog egyirányű protokoll, nem tud visszaadni hibaüzenetet (mert nincs miről)."
Ez is elhangzott párszor, a syslog valóban egyirányú protokoll (az viszont nem igaz, hogy nincs miről hibaüzenetet visszaadni). Pont a fentebb is említett RFC hangoztat egy halom olyan esetet, amiket hibának minősítenek. Az is elhangzott, hogy a syslog nem használ pl.: socket-eket (ami szinte azonnal megcáfolásra került), illetve az UDP mint példa is felmerült (amit utána az egyik kedves hozzászóló végig hangoztatott mint ellenérv, annak ellenére hogy ki lett fejtve hogy példa), miszerint az UDP ugyanúgy egyirányú kommunikációs forma (mégis történhet hiba).
A hibák kifejtése már fentebb megtörtént, erre nem pazarolnék szót.

Összegezve elmondható tehát: a libc -s implementáció jelen pillanatában az összes felmerülő hibát eltünteti (kezelésként fixen behaxolt magic number/retry loop/errno buzerálás van), a szabvány a visszatérési értékről rendelkezik (hogy nem lehet), de arról nem hogy hibát nem jelezhet az adott hívás, sőt, maga a szabvány definiál több hibát (amit a libc -s implementáció szépen eltüntet).

Innentől kezdve az emberek két táborra szakadtak:
1. tábor: akik szerint teljesen normális hogy a rendszer szintű, illetve a specifikáció által definiált hibákat teljes egészében el rejtheti valami, azzal a felkiáltással, hogy ha a programozó tudhat róla hogy hiba van, az csak szar programot/szar kódot eredményez.
2. tábor: akik szerint nem elfogadható az, hogy egy implementáció bármilyen formában elrejti azokat az információkat amikkel rendelkezik, illetve semmilyen információt nem közöl arról, hogy a metódustól elvárt feladatok megtörténtek-e/vagy sem. (a specifikáció által jelzett hibák elnyeléséről már szót sem ejtve)

És akkor itt az egyéni, szubjektív véleményem: Mivel én a 2. táborhoz tartozom, egyszerűen nem tudom megérteni az 1. tábor álláspontját (akik a hibakezelést továbbra is telibeszarhatnák a visszajelzés ellenére is). Képtelen vagyok felfogni, hogy vannak olyan programozók, akik a hibakezelést egyszerűen a gonosztól eredendőnek tekintik.
Részemről itt a téma lezárva, kár rá további szót pazarolni, mert nem fog senki meggyőzni arról, hogy a hibakezelés rossz dolog és szar kódot eredményez

Az errno értéke csak akkor értelmezett, ha a függvény visszatérési értéke azt jelzi, hogy az errno valid értéket tartalmaz.
"The value of errno should only be examined when it is indicated to be valid by a function's return value."
Azaz definíció szerint a visszatérési érték nélküli (void) függvények nem módosíthatják az errno értékét.

Persze ha a GNU-s arcok szarnak a szabványra, az is jó, csak akkor ne akarják, hogy homokozós óvodásoknál többre tartsák őket.

"1. tábor: akik szerint teljesen normális hogy a rendszer szintű, illetve a specifikáció által definiált hibákat teljes egészében el rejtheti valami, azzal a felkiáltással, hogy ha a programozó tudhat róla hogy hiba van, az csak szar programot/szar kódot eredményez."

Nem. Arról van szó, hogy tervezési időben (implementációra nem gondolunk) el kellett dönteni, hogy az adott függvényhívásban keletkezik-e olyan hiba (implementáció-függetlenül), amit vissza lehet adni.

Példa: javaban ha egy exceptiont nem kezelsz le, throw-val jelezni kell, hogy azt tovább dobod. Előfordulhat, hogy tervezéskor nem gondoltak arra, hogy az implementációban adott típusú exception keletkezhet, ezért úgy terveztek meg egy metódust, hogy az nem dob adott típusú exceptiont (ez nem feltétlenül tervezési hiba, hiszen lehet, hogy egy másik implementációban egyáltalán nem keletkezhet adott típusú exception). Te implementálod a metódust, és rájössz, hogy keletkezik egy ilyen exception, amit adott esetben helyben nem tudsz lekezelni, ezért tovább dobnád. Az alábbi megoldásokból választhatsz:

  1. átírod a metódus deklarációját, hogy az dobhasson adott típus exceptiont, ezzel megborítva a megtervezett apit, vagyis minden megírt kódot, ami a metódust hívja
  2. becsomagolod az exceptiont egy RuntimeExceptionbe, és dokumentálod hogy aki meghívja a metódusod az gondoljon rá hogy keletkezhet egy RuntimeException is
  3. becsomagolod az exceptiont egy olyanba amit dobhat a metódus, és dokumentálod hogy a metódus lehet, hogy nem is olyan hibára dobja az exceptiont, mint amire azt kitalálták
  4. becsomagolod a kérdéses kódot egy try-catch blokkba, és a catch ágban nem csinálsz semmi érdemlegeset (persze lehet logolni, exit-et hívni vagy ami tetszik, de olyat nem fogsz tudni csinálni hogy a hívó kezelhesse a hibát)

Ezek közül szerintem a 4-es a legkevésbé rossz.