PHP kivételkezelés baki

hm, érdekes. mondhatni lol. írj egy switch(get_class($e))… -t a legutolsó blokkba és kezeld ott le az eseteket a különböző kivételekre, jobb ötletem nincs:D

[re=6064140]Mefi[/re]: Hahaha! Szép kód nincs, a saját kódod is csak most szép, majd megnézed pár év múlva, és egy nagy trágya gányolásnak fogod látni a szép kódodat. A másé pedig mindig ronda 🙂

Apropó, az RSS-ben nem jött át a kódrészlet, valamint a kódrésznél nem kéne bele sortörés, itt inkább a vízszintes scrollbar lenne jó helyette…

Igazi informatikusként belepofáztam, viszont a megoldást nem tudom 🙂 Érdemes lenne utánanézni, mitől van ez, szerintem működnie kéne.

class EgyikKivetel extends Exception {
}

class MasikKivetelException extends Exception {
}

class Ojjektum {
public function kiveteltHajigaloMuvelet() {
throw new MasikKivetelException();
}
}

try {
$ojjektum = new Ojjektum();
$ojjektum->kiveteltHajigaloMuvelet();
} catch(EgyikKivetel $ek) {
die(‘EgyikKivetel, osztálya: ‘ . get_class($ek));
} catch(MasikKivetelException $mk) {
die(‘MasikKivetel, osztálya: ‘ . get_class($mk));
} catch(Exception $e) {
die(‘Exception, osztálya: ‘ . get_class($e));
}

5.2.17 és 5.3 alatt is a MasikKivetelException-ba fut be nálam.

Pont a minap láttam én is valami kapitális hülyeséget, amire ha megőrülök, sem bírok rájönni, hogy mitől volt. Metódusok felülbírálása miatt nyavajgott valamit szegény interpreter, hogy a gyerek osztály metódusa nem kompatibilis a szülőével (type hinting rulez). Mindezt olyan szituációban, amin nyilvánvalóan látszott, hogy márpedig kompatibilis. (Arról már nem is beszélve, hogy felülbírálásnál sok esetben nem is szól, ha a gyerek osztályban teljesen megváltozik egy metódus szignatúrája.) Sőt, amikor próbáltam összehozni egy tökéletesen ugyanolyan példakódot, akkor meg már megette. Félóra szenvedés után megoldottam inkább máshogy, és azóta már el is felejtettem, de ha lesz egy kis időm, megpróbálom reprodukálni. A lényeg: 5.3 volt. 🙂

Btw. ha már tiszta kód, akkor hagy reklámozzam engem: http://www.slideshare.net/athoshun/clean-code-7698174

[re=6064151]saxus[/re]: szvsz feladata válogatja. (További refaktorizációval egyébként még ettől a problémától is meg lehet szabadulni.)

[re=6064158]Mefi[/re]: lehet, csak en vagyok ilyen szerencsetlen, de tobbet szivtam eddig kilometeres (ertsd: agyonbonyolitott, kepernyo jobb szeleig indentalt) fuggvenyek es svajcibicska osztalyok miatt, mint mar-mar “elaprozodott” osztalyhierarchiaval. Utobbi altalaban egyutt jar sok-sok unit teszttel, amik mar eleve meg tudjak sporolni egy rakas hiba kinyomozasat, illetve amikor a tesztek egy csoportja hibat jelez, maris konnyebben tudja az ember, hova kell nyulni (foleg, ha legalabb minimalis szintu DI is hasznalatban van). A hatvanadik osztalyig jo esellyel azert tud elgyuruzni egy problema, mert mar eleve gondok vannak a kod architekturajaval. Law of Demeter rlz. 🙂

A tulzott es az elnagyolt absztrakcio kozotti egyensuly megtalalasa persze nem egyszeru feladat. Sot sokszor jobb eredmenyre vezet azutan helyreallitani, miutan mar felborult, hiszen akkor mar pontosan tudja az ember, milyen problemakat akar/kell megoldani a kod felepitesevel kapcsolatban. Ezek az elvek nem okolszabalyok, csak segitenek eszrevenni, mikor mar elkezd recsegni a kod szerkezete.

[re=6064161]saxus[/re]: U R doin it rong. Nem a globalis valtozok, singletonok es egyebek ellen szolnak ezek az elvek ugy _altalaban_. (Btw. vicces bugokat okozhat, ha hasznalsz ket modult/libet/akarmit, amik kozott globalis valtozo neve utkozik.) Inkabb arrol van szo, hogy van az a kodmeret (tapasztalataim szerint nagysagrendekel 1M loc alatt), amikor mar megeri a ragasztoszalag nagy reszet kikaparni a kodbol, es feltakaritani az architekturat. Nem kell egybol urhajot epiteni, eleg, ha a bicikli szogletes kereket kicsereli az ember egy kerekebbre, hogy konnyebben guruljon. Egy egyszerubb webshopnal, blogmotornal jo esellyel teljesen felesleges ilyesmivel tolteni az idot, de ahogy a kod hizik (uj ficsorok, clever hack-ek, gany workaroundok), elobb-utobb eljon az a pont, amikor nagyjabol harom opcio kozul lehet valasztani: 1. meghal a project, 2. ujrairjak nullarol, 3. ki kell takaritani az architekturat. Ezt egyebkent sokszor epp egy nagyobb feature hozzaadasa generalja. A negyedik lehetoseg, irrealis idot aldozni a hibak tovabbi, veget nem ero foltozgatasara, ilyenkor mar egyszeruen nem eri meg.

Ha a kodod akkora vagy olyan, hogy a DI bonyolitja ahelyett, hogy egyszerusitene, akkor valoszinuleg nincs eppen ott szukseged ra, ne hasznald, ilyen egyszeru (pont errol szol a tortenet). Nem art viszont tudni, hogy mi fan terem, kulonben akkor sem fogod hasznalni, amikor valoban szukseged lenne ra (hiszen eszre sem fogod venni, hogy az adott esetben DI kellene). Ha megengeded, ideznelek (no offense):

-8<------------------------ „Ne használd, mert vannak ”programozók", akik nem tudják, hogy mire való." Az ilyenekre meg annyit tudok mondani, hogy nem kell minden gyökérnek programozónak menni. -8<------------------------ A gotoval egyebkent semmi gond nincs, C-ben pl. van letjogosultsaga, a hibakezeles ismetlodeset szepen el lehet vele kerulni (vo: exception-ok mas nyelvekben). Baj akkor van, amikor egy trivialisnal bonyolultabb algoritmus szerves reszekent talalkozol vele, amely algoritmusban epp egy hibat szeretnel megtalalni es kijavitani. (Van oka annak, hogy az assembly kiszorult a mainstream szoftverfejlesztesbol, ugy ertem, reverse engineering vagy forditoiras kozben peldaul hasznos, de blogmotort valoszinuleg valami mas nyelven irnek.) Szeretem en is a frappans megoldasokat, ugyes hackeket, de aki utanam kovetkezokent nyul majd a kodomhoz, azt nem azert fizetik, hogy ezeket kerulgesse. Ha nem botlanek lepten-nyomon epic facepalmokba mindenfele legacy kodokban, amikkel osszeakadok, eszem agaban sem lett volna ennek a temanak utanaolvasni.

“Ha nem botlanek lepten-nyomon epic facepalmokba mindenfele legacy kodokban” 😀 fuck yeah