Try, catch, except - kivételkezelés, hibakezelés?

Try, catch, except - kivételkezelés, hibakezelés?
2018-08-12T18:38:18+02:00
2018-08-14T01:56:08+02:00
2022-10-18T16:40:37+02:00
  • nem tudtad try / catch nelkul megoldani

    Szakmai életem felét olyan nyelvekkel töltöttem, ahol nem volt try/catch... és túléltem.
    Amikor először találkoztam vele, azt gondoltam: de hiszen enélkül is meg tudom csinálni amit akarok ill. kell, ez felesleges.
    Később megértettem a lényegét és a bennem megbújó felfedező "látá, hogy ez jó".

    Szakmai életem felét olyan nyelvekkel töltöttem, ahol nem volt class... és túléltem.
    Amikor először találkoztam vele, azt gondoltam: de hiszen enélkül is meg tudom csinálni amit akarok ill. kell, ez felesleges.
    Később megértettem a lényegét és a bennem megbújó felfedező "látá, hogy ez jó".

    Szakmai életem felét olyan nyelvekkel töltöttem, ahol még nem voltak pattern-ek... és túléltem.
    Amikor először találkoztam vele, azt gondoltam: de hiszen enélkül is meg tudom csinálni amit akarok ill. kell, ez felesleges.
    Később megértettem a lényegét és a bennem megbújó felfedező "látá, hogy ez jó".


    Sok mindent csinálok, annyira nagyra nőtt a szakmai világ, hogy nem tudok és nem is akarok olyan új dolgokkal foglalkozni, amik nem jönnek szembe valamilyen munkával ill. feladattal kapcsolatban.
    A nagy lelkesedést a mindenféle újdonságokra meg majd kinövitek. Mondja a tapasztalt vén.

    Ha azt tudnám/érteném mélyebben-szélesebben, amire valóban szükségem van (mert pár évtizednyi tanulás is kevés!)... na már annak is örülnék, mert ugye Dunning–Kruger is megmondta :)
    Ezt ugyan nem közvetlenül neked címeztem, de nagy igazság: "Javaslom a tudásod bővítését funkcionális programozás irányában, elsősorban a monádok irányába."
    Mutasd a teljes hozzászólást!
  • Ezutan nem csodalom, hogy nem tudtad try / catch nelkul megoldani a problemat.
    Mutasd a teljes hozzászólást!
  • A haskell megkozelitese kivalo pelda a hibakezelesre, modern, megbizhato formaban, es eleg sok cikk van online ami ennek az implementalasaval foglalkozik C++ kornyezetben.

    Sok elonye van az exceptionokkel szemben, arrol nem is beszelve, hogy igy egyszerubb mellekhatas nelkuli fuggvenyekkel dolgozni. :)
    Mutasd a teljes hozzászólást!
  • Azért az igazi királyság az ONERRORGOTO volt, ismerjük el!
    Mutasd a teljes hozzászólást!
  • 4) Vannak esetek, amikor nem akarunk hibát kezelni, hanem egyszerűen csak tovább akarjuk adni azt a hívónak. Ilyenkor mi a helyzet?

    Olyankor nem kezeljuk, hanem tovabb adjuk a hivonak.
    Mutasd a teljes hozzászólást!
  • Nyilvan valoan exceptionos nyelvel is mindent meg lehet, a c++, java, c#, python egyutt talan a kodok haromnegyedet is kiteszik es ezek exceptiont hasznalnak.

    En arrol beszeltem ami nekem jobban bevalt es miert, nem arrol hogy exceptionnel ne lehetne akarmilyen jo kodot irni.
    Mutasd a teljes hozzászólást!
  • Részletekben elmerülés nélkül annyit azért hozzátennék, hogy ha valaki nagyon ragaszkodik a hibakódokhoz, akkor végülis a "9-es szinten" elkapja az összes kivételt (ezt a fordító biztosítani tudja), és utána a többi szinten már mehet a hibakódok passzolgatása. Ehhez persze az kell, hogy legyen egy kinevezett illesztőfelület, és a fújfújkivételes könyvtárral csak az beszélgessen.
    Mutasd a teljes hozzászólást!
  • Most arról beszélnük, hogy mind a 9 szint külön-külön kiírja a képre, hogy "Te figyuzz má', az osztónak nem kéne nullának lennie!"? 

    Nem. Arrol amikor mind a 9 szint tud valamit csinalni. A legtobb hiba abbol van, hogy elfogyott valamelyik eroforras, nem elerheto valamelyik szolgaltatas es hasonlok. Pl ha el akarok menteni egy infot, akkor mentes fgv nem akarom hogy exceptiont dobjon amig nem fogytak el a lehetoseg. A hibatol fuggoen problaja ujra, probalja ujra kesobb, hasznaljon masik starge mechanizmust. Egy szintel lejjebb a storage mechanizmus szinten ne dobjon excepiont ha kezelje a hibakat amig lehet. Ha olyan a hiba akkor meg ugyis visszajut az elso retegbe, de kozben minden reteg tudja monitorozni magat, kezelni a failover megoldasokat.

    Nyilvan mindent meg lehet csinalni exceptionnel is, nem mondom hogy nem, de nem mindenhol az a legjobb. Es amikor nem az a legjobb, eleg korulmenyes lesz a fejlesztes ha exceptiont dobal a kod amit nem te irtal.
    Mutasd a teljes hozzászólást!
  • A try-catch szerkezet az egyik legrosszabb módja a hibakezelésnek, gyakorlatilag a modern goto.
    Itt írok róla (Java), de még nincs kész.

    Ház ez valóban nincs kész...

    1) Sok súlyos állításod van, amiket 1-2 mondat "magyarázattal" elintézel. Linkelj forrásokat vagy fejtsd ki ezeket. (Pl.: "prototípusok létrehozásához. Ilyenek pl. dinamikus típusosság, exception, ..."; map/flatMap, mint hibakezelési mechanizmus; exception = goto)

    2) A cikk konklúziója az, hogy az Either használata jobb, mert egyszerűbb. Miért egyszerűbb? Mert linkeltél egy videót az egyszerűségről? Fejtsd ki! Igazából erről kellene, hogy szóljon az egész cikk, de egy példakódon kívül nem tartalmaz semmi konkrétat.

    3) Ha már egyszerűségnél tartunk, akkor egy hibakód visszaadása az Eithernél is lényegesen egyszerűbb. Igazán megemlíthetnéd ezt a hibakezelési módot is az írásodban, hiszen az egyszeri olvasó jogosan gondolhatja, hogy ha visszaadhatsz egy struktúrát vagy egy számot, akkor a második sokkal kézenfekvőbb.

    4) Vannak esetek, amikor nem akarunk hibát kezelni, hanem egyszerűen csak tovább akarjuk adni azt a hívónak. Ilyenkor mi a helyzet?
    Mutasd a teljes hozzászólást!
  • Ha viszont azt szeretned hogy megis minden reteg kezelje a hibat akkor eleg maceras megcsinalni, ha pl a lib amit hasznalsz kizarolag exceptionnel kommunikalja a hibat.

    Most arról beszélnük, hogy mind a 9 szint külön-külön kiírja a képre, hogy "Te figyuzz má', az osztónak nem kéne nullának lennie!"? Egy hibát egy helyen szokás kezelni, a stack unrolling meg a gc pont arról szól, hogy arra az egy helyre erőforrás-szivárgás nélkül vissza lehessen jutni és így a közbülső rétegeknek tényleg ne legyen semmi dolga hiba esetén, ha egyszer úgysem tudják önmagukban lekezelni - ez nem mellékhatás, hanem cél.
    Mutasd a teljes hozzászólást!
  • Ezt miből gondolod?

    Exceptionnel nem megy vissza a vezerles minden egyes fuggvenyhivashoz, amin keresztul elert az exceptionhoz, hanem rogton a legkozelebbi catch blokkba ugrik, azon kivul csak a peldanyok destruktorai hivodnak meg (meg persze a gc eldobolja amit kell, ha van).

    ha a közbülső 9 réteg nem tud mit kezdeni a kivétellel, akkor nem muszáj neki.

    Ha viszont azt szeretned hogy megis minden reteg kezelje a hibat akkor eleg maceras megcsinalni, ha pl a lib amit hasznalsz kizarolag exceptionnel kommunikalja a hibat.
    Mutasd a teljes hozzászólást!
  • Pont az melyen egymasba agyazott blokkokbol adodik konnyen problema. Ha 10 retegen keresztul megy valami es a 10. retegben exception keletkezik, akkor nem rollbackelodik vissza mint a 10 retegen keresztul, mindenhol megfeleloen kezelve

    De, pontosan így működik egy kivétel (bár a "rollback" itt nyilván teljesen téves szó használat). Sőt, akkor is "mindenhol megfelelően kezelésre" kerül a hívott eljárásokban, ha látszólag azokban nincs is try-except, de van olyan erőforrás létrehozva bennük, amit egy kivétel esetében fel kell szabadítani. Pl. dinamikus sztring, lokális referenciaszámolt objektum, stb.

    Kiveve persze ha minden retegben csinalsz egy try/catch blokkot, de az meg syntactik sugar a visszatersi ertekes verziora.

    Egyrészt a "syntactic sugar" tök mást jelent - olyan szerkezetet, amit le lehet írni más nyelvi szerkezet(ekk)el is, csak hosszabban. A kivételek nyilván nem ilyenek, mert azok teljesen másként működnek, mint bármilyen más, létező nyelvi szerkezet. Sőt, az olyan fejlett kivételkezelés, mint pl. a Java-é, még rengeteg plusz kóddal sem "emulálható" a nyelvben (lásd pl. checked exception-öket, amiket egyszerűen nem tudsz utánozni kódból, hanem magának a fordítónak/nyelvnek kell ismernie, támogatni azok koncepcióját ahhoz, hogy működhessenek).

    Másrészt ha egy rétegbe try-catch blokkot raktál, akkor annak oka volt - mert akkor ott van valami (tipikus erőforrások felszabadítása), amit el kell végezni mindenképpen, mielőtt a vezérlés elhagyná az adott végrehajtási egységet, legyen ennek bármi oka is. És akkor oda a try-catch-be ez a művelet is bekerül.

    En nem latok sok hibalhetoseget ebben, mert a fordito rakenyszerit hogy vagy explicit ignorald a hibat, vagy csinalj valamit az error valtozoval.

    A legtöbb generikus nyelvben nem lehet rákényszeríteni a fordítót arra, hogy szóljon, ha pl. egy függvény visszatérési értékével nem csinálsz semmit (sokszor a szigorúan out paraméter értékével sem, sőt, eleve a szigorúan out paraméterként jelölés sem megoldott sok nyelvben). Márpedig hibakódokat, illetve a végrehajtás sikerességére vonatkozó információkat - már csak praktikus okokból is - így szokás visszaadni.

    Ertem en az exceptionoket, csak jobban szeretem ha explicit vannak kezelve minden retegben, mert igy kevesebb a meglepetes.

    A kivételekkel mindent megcsinálhatsz, amit a hagyományos hibakód-vizsgálattal is, csak éppen használatuk esetében elég azt a kódot megírnod, aminek a "hiba" fellépésekor kell végrehajtódnia, és nem kell annak a kódnak a megírásával bajlódnod, ami maga a hiba meglétét vizsgálja vagy annak részleteit adogatja felfelé, a különböző rétegeken át.

    Bár mint korábban írtam, a kivételek nem a szó szoros értelmében vett hibakezelésre valók, illetve szokás használni őket, hanem arra, hogy egyszerűen tudjuk a vezérlést a program egy adott pontjára juttatni akkor, ha olyan állapot lép fel abban vagy olyan esemény történik, ami az adott logikai egységben következő _összes_ további művelet végrehajtását szükségtelenné vagy megkísérlését értelmetlenné, lehetetlenné teszi.

    Az egymásba ágyazott if-ekből álló hibakezelés is lényegében pontosan ezt csinálja, csak sokkal több kódból, sokkal körülményesebben.
    Mutasd a teljes hozzászólást!
  • akkor nem rollbackelodik vissza mint a 10 retegen keresztul

    Ezt miből gondolod?

    mindenhol megfeleloen kezelve, hanem egyszeruen kiugrik az elso catch blokkhoz, a kozbulso 9 reteg meg nem tud az exceptionrol

    Mondjuk ez csupán a lényeg volna: ha a közbülső 9 réteg nem tud mit kezdeni a kivétellel, akkor nem muszáj neki. Viszont az objektumok, erőforrások közben nem leakelnek el. Pont, hogy van rollback.
    Mutasd a teljes hozzászólást!
  • Nem, tévedés. Ez nem egy syntax sugar, és nem is hasonlítható try/catch szerzetre. Ez egy Option adattípus (Maybe monád) és egy egyszerű mintaillesztés.

    Javaslom a tudásod bővítését funkcionális programozás irányában, elsősorban a monádok irányába. Esetleg próbáld ki a Haskell nyelvet. Ott egyáltalán nincs try-catch szerkezet. A hibakezelés is monádokkal van megoldva. Nem azt mondom, hogy szerintem szép a monádos megoldás, csak azt, hogy ez egy megoldás például rá. Szemléletbővítésre mindenképp jó. 
    Mutasd a teljes hozzászólást!
  • Pont az melyen egymasba agyazott blokkokbol adodik konnyen problema. Ha 10 retegen keresztul megy valami es a 10. retegben exception keletkezik, akkor nem rollbackelodik vissza mint a 10 retegen keresztul, mindenhol megfeleloen kezelve, hanem egyszeruen kiugrik az elso catch blokkhoz, a kozbulso 9 reteg meg nem tud az exceptionrol. Kiveve persze ha minden retegben csinalsz egy try/catch blokkot, de az meg syntactik sugar a visszatersi ertekes verziora.

    Ha pedig tucatnyi rétegen kell visszapasszolgatni, akár csak egy true/false flagget, akkor az nemcsak kényelmetlen, de sokkal nagyobb hibalehetőség is.

    En nem latok sok hibalhetoseget ebben, mert a fordito rakenyszerit hogy vagy explicit ignorald a hibat, vagy csinalj valamit az error valtozoval.

    Megnyugtatlak, az exception dolgot vagy harmadjára-negyedjére magyaráztam el diákoknak, mire én is "ráéreztem" a mélyben megbújó nagy igazságokra

    Ertem en az exceptionoket, csak jobban szeretem ha explicit vannak kezelve minden retegben, mert igy kevesebb a meglepetes.

    Nyilvan en is meg tudom nezni az exception logot, nem arrol van szo, hanem arrol hogy nagyobb hanyagsagot enged meg az exception.
    Mutasd a teljes hozzászólást!
  • A kérdés nem a "lehetséges-e?" volt, hanem az, hogy "sok ilyet ismersz?".

    Scala kodoknal eleg gyakori.
    Mutasd a teljes hozzászólást!
  • Nyilván azért írtam oda, hogy "valami struktúra", mert el bírtam képzelni ezt a megoldást.
    A kérdés nem a "lehetséges-e?" volt, hanem az, hogy "sok ilyet ismersz?".
    Mutasd a teljes hozzászólást!
  • match x {
      Some(x) => "az osztas eredmenye {x}"
      None => "Nullaval nem osztunk"
    }

    No de kérem ez csak syntax sugar egy try/catch szerkezetre 
    Mutasd a teljes hozzászólást!
  • Nem tudod hogy milyen exception fog valahonnan elobukkanni es az idok folyaman ez meg valtozhat is ha valahol az alsobb retegekben bekerul egy uj exception, vagy akar megvaltozik.

    Nono!
    Egy alsóbb rétegből előkerülő váratlan/új/eddig nem kezelt hiba pont az exception esetén kerül egységes és standard lekezelésre!
    Ismeretlen új hiba esetén ugyan nem tudom tájékoztatni a usert a pontos 'okról', de a hibás 'következményt' pontosan el tudom kerülni.

    És az exceptionnak pont az a lényege, hogy blokkokba ágyazott blokkokba ágyazott blokkokba ágyazott blokkokkal építkezve nagyon nem is érdekel, hogy az általam használni kívánt objektum adott metódusa (illetve az alatt 10 réteggel valami) miért is nem fut, a lényeg hogy nem fut és ezt pontosan lekezelem. (Innen komponens alapú szemlélet)
    Mint tranzakció esetén, commit/rollback... hogy a mélyben mi is volt az ott nem kezelhető baj, azt örülök ha megkapom a magasabb szinten, az is fontos a program komfortfokának (pl. próbálja-e retry-t vagy szálljak ki döntéshez, milyen üzenetet adjak), de az első és legfontosabb hogy tranzakció szerűen biztosítsam a sikeres/sikertelen ágak helyes futását.

    Ha pedig tucatnyi rétegen kell visszapasszolgatni, akár csak egy true/false flagget, akkor az nemcsak kényelmetlen, de sokkal nagyobb hibalehetőség is.
    Gyakran előfordul, hogy nem igazán érdekel 20 rétegen át a hibakód, ha lefut akkor fusson, ha meg megakad úgysem tehetek semmit, majd a végén(!) kapok róla infót, mert az egész vertikális kódbázist egyetlen try-ban lekezelem.

    Megnyugtatlak, az exception dolgot vagy harmadjára-negyedjére magyaráztam el diákoknak, mire én is "ráéreztem" a mélyben megbújó nagy igazságokra.
    Hiába no, zseninek születni kell és sokan vagyunk halandó köznapi emberek.
    Mutasd a teljes hozzászólást!
  • Hát, ehhez olyan visszatérési érték kéne, ami egyszerre visszatérési érték és kivétel, szóval általános esetben valami struktúra. Sok ilyet ismersz? Vagy a átláthatóság alatt az "out" meg "inout" jellegű argumentumok kötelető használatát kell érteni?

    Pl igy:
    x = div(1,0)

    match x { Some(x) => "az osztas eredmenye {x}" None => "Nullaval nem osztunk" }
    Ilyen jellegu kodot sok nyelven lehet irni. Igy az x-el nem fog tudni tovabb dolgozni a kod ugy mintha jo lenne, es rogton az elso ponton ahol hiba van, valamit csinalni kell vele.

    A masik hasznos dolog ha egy a div montjuk (int, error) tipussal ter visza, akkor amikor meghivod:
    y, div_err = div(1,0)-kent es utana nem csinalasz valamit  div_err-el akkor le sem fordul a program go-ban.

    ha meg y, _ = div(1,0)-kent hivod meg akkor ott explicit le van tojva a hibakezeles, igy az is latszik.

    Ezzel szemben az exceptionoknel ezek jobban el vannak rajtve, ott siman ki tudod hagyni a hibakezelest ugy hogy egyszeruen elfelejted. Ahol a fordito szol erte, ott persze nem.
    Mutasd a teljes hozzászólást!
  • A visszateresi ertek ellenorzos verzio, nem bonyolult vagy atlathatatlan

    Amint több rétegen keresztül kell visszaadnod, onnan nagyon átláthatatlan bír lenni. (a try a megszakítás figyelésen kívül "egységbe fog" így az értelmezhetőséget is nagyban javítja)
    Különösen, ha minden rétegben tucatnyi önálló ág indul, amik értelem szerűen saját hibavisszatérési kóddal/strukturával rendelkeznek.
    Mutasd a teljes hozzászólást!
  • Pár, mástól származó, nem a te hibakezelési konvenciódat alkalmazó könyvtár belinkelésével is?
    Jujj!

    Igen lehet nagyon jó alternatívákat készíteni... de minek is, amikor van egy tudományosan-szakmailag konszenzusos és bevált, egységesen alkalmazott módszertan. :)
    Mutasd a teljes hozzászólást!
  • A visszateresi ertek ellenorzos verzio, nem bonyolult vagy atlathatatlan, csak kopik a billentyuzet.

    Hát, ehhez olyan visszatérési érték kéne, ami egyszerre visszatérési érték és kivétel, szóval általános esetben valami struktúra. Sok ilyet ismersz? Vagy a átláthatóság alatt az "out" meg "inout" jellegű argumentumok kötelető használatát kell érteni?

    A try/catch-es kod rovidebb viszont nem atlathatobb.

    Nyilván egyre gondolunk, én pl. egy ötszintű hívási gráfra.

    Nem tudod hogy milyen exception fog valahonnan elobukkanni es az idok folyaman ez meg valtozhat is ha valahol az alsobb retegekben bekerul egy uj exception, vagy akar megvaltozik.

    Mondjuk egy csomó környezetben le se fordul a kód, amíg nem rakod körbe vagy kivételkezeléssel, vagy továbbdobással. Ahol meg nem, ott futás közben a kivétel megmondja, hogy honnan jött. Azt, hogy a -8-as visszatérési értéket elfelejtetted lekezelni, semmilyen fordító nem tudja megmondani és futásidőben sem derül ki.
    Mutasd a teljes hozzászólást!
  • Engem érdekelne erről valami infó (minták, példák, stb.). 

    A visszateresi ertek ellenorzos verzio, nem bonyolult vagy atlathatatlan, csak kopik a billentyuzet.

    A try/catch-es kod rovidebb viszont nem atlathatobb. Nem tudod hogy milyen exception fog valahonnan elobukkanni es az idok folyaman ez meg valtozhat is ha valahol az alsobb retegekben bekerul egy uj exception, vagy akar megvaltozik.
    Mutasd a teljes hozzászólást!
  • A try-catch szerkezet az egyik legrosszabb módja a hibakezelésnek

    A try-catch nem hibakezelési, hanem vezérlési szerkezet. Az, hogy úgymond hibakezelésre is lehet használni, egy dolog. De értelmes ember 99%-ban nem a hibák, azaz nem várt végrehajtási problémák, akadályok kezelésére, hanem igenis várt helyzetek bekövetkezése esetén a program végrehajtásának egy adott ágra terelésére használja. Amiben benne van az is, hogy esetleg nem sikerül valamilyen műveletet elvégezni, véghezvinni - de ez nem hiba, vagy legalábbis nem a szó fent részletezett értelmében.

    gyakorlatilag a modern goto.

    Minden a programutasítások szigorúan sorban és előrefelé történő végrehajtását megbontó szerkezet "gyakorlatilag egy modern goto". Sőt, még a lineáris végrehajtás és minden elemi utasítás is egy goto, mert növeli a programmutatót úgy, hogy a végrehajtás a következő sorra ugorjon. Márpedig az ugrás ugye goto.

    A try-catch szerkezet az egyik legrosszabb módja a hibakezelésnek, gyakorlatilag a modern goto.
    Itt írok róla (Java), de még nincs kész.

    "Egy exception dobás tulajdonképpen ugyanaz, mintha egy goto utasítást hajtanánk végre. Ami kicsit még rosszabbá teszi, hogy pontosan nincs is meghatározva, hogy hová fog ugrani, ráadásul több helyre is ugorhat."
    Bocs, de az ilyenek után az kell mondanom, hogy ne is fejezd be, hanem dobd ki úgy, ahogy van. Aztán nézz utána, hogy hogyan is működik (különösen a generált kód szintjén) és hogyan is szokás használni a kivételeket, illetve a kivételkezelő szerkezetek (mert jelenleg nyilvánvalóan nem tudod és érted a működésüket), és amikor már tényleg tudod és érted, akkor gondold át még egyszer, hogy tényleg akarsz -e egy ilyen negatív kritikát írni róluk. Szerintem nem fogsz akarni.

    Csak a félreértések elkerülése végett, az idézettel kapcsolatban: a kivételnél természetesen pontosan meg van határozva, hogy a vezérlés hogyan és hova ugrál (úgy és annyira, ahogy egy return-nél is megvan határozva), és nem, try-catch esetén sem ugrál több helyre, még abban az értelemben sem ahogy te gondolod, hanem mindig egy helyre ugrik, és onnan legfeljebb akkor ugrik tovább máshova, ha az eredeti vagy egy másik kivétel újra raise-elésre kerül, ami viszont gyakorlatilag már egy másik kivétel, ami megint csak pontosan egy helyre ugrik vissza, abban az értelemben ahogy te érted.
    Mutasd a teljes hozzászólást!
  • Try Catch nelkul is lehet nem bonyolult, atlathato hibakezelest irni.

    A try-catch szerkezet az egyik legrosszabb módja a hibakezelésnek, gyakorlatilag a modern goto.
    Itt írok róla (Java), de még nincs kész.

    Engem érdekelne erről valami infó (minták, példák, stb.).

    Az alábbiak Scala-s példák, de ilyen konstrukciókat (mint az Option, Either, ...) lehet más nyelveken is létrehozni:

    Easing Into Functional Error Handling in Scala

    Managing errors the right way in Scala

    Bill Venners, Scalactic, SuperSafe, and Functional Error Handling
    Mutasd a teljes hozzászólást!
  • Hali!

    Try Catch nelkul is lehet nem bonyolult, atlathato hibakezelest irni.

    Engem érdekelne erről valami infó (minták, példák, stb.). 

    Mutasd a teljes hozzászólást!
  • Try Catch nelkul is lehet nem bonyolult, atlathato hibakezelest irni. Neked nem sikerult, de attol meg van alternativa.
    Mutasd a teljes hozzászólást!
  • Persze, azt is jelentheti, a lenyeg hogy nehezebb elfelejteni (nekem).
    Mutasd a teljes hozzászólást!
  • olyan buntudat keltes keppen

    Vagy jelzésképpen, hogy átgondoltam, megterveztem 

    Vagy mert nem fordulhat elő (logikai alapon, pl. mert előzetes ellenörzés történt a hibahelyzetre) vagy mert tudom, hogy továbbengedhetem, mert itt úgysem tudnám korrekten (azaz igazán értelmesen) lekezelni, vagy mert egy alacsonyabb szinten lesz a jó helye a lekezelésnek.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd