- gban: Ingyen kellene, de tegnapra
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- N€T0X|N: Stellar Blade után
- pr1mzejEE: Viszlát CoD2, CoD4, CS:GO!
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- weiss: Pant* rant
- Bezzeg annak idején...
- leslieke: leslieke farmerzsebe
- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
"Kivételkezelést akkor érdemes használni, amikor egy mély hívássorozat alján keletkezik valahol egy kivételes hiba, és ezt sokkal fentebbi függvényben akarod lekezelni. Ilyen például az adatbázis absztrakciós rétegekben egy mysql hiba, ami, ha jó a kódod, ritkán fordul elő, és általában elég csak annyira foglalkozni vele, hogy loggolod."
1.) Nem értem, ez miért változtat azon az állításomon, hogy átláthatóság szempontjából mindenképp jobb. Azt hittem, a privátban kitárgyalt kód meggyőző volt ennek alátámasztására.
2.) A MySQL-hiba jobb esetben - pl. elég ritka, hogy az adatbázishoz tartozó service lehal - valóban ritkán fordul elő. De azért ne csináljunk úgy, mintha csak ennyire szélsőséges esetekre lehetne alkalmazni a kivételeket."Ha a kivételkezelést általános programozási gyakorlattá teszed, annak megvan az a hátránya, hogy később, ha ránézel a kódra, nem biztos, hogy fogod tudni, hogy a kivételedet hol dobod (ahogy említetted, amíg ténylegesen nem történt ilyen exception, akkor stacktrace), és amikor refaktorálod a kódot, fogni fogod a fejed."
Ezt pontosan azért nem értem, mert az előző hozzászólásomban éppen azt hoztam fel a kivételek egyik előnyeként, hogy a lehető legegyszerűbb kideríteni, honnan származik a kivétel, és naplózás esetén nálam legalábbis alap, hogy a kivételek forrását is naplózom: melyik fájlban keletkezett a kivétel, melyik függvényben, a fájlnak pontosan melyik sorában, mikor, stb. Ezeket az exceptionökből a lehető legegyszerűbb feladatok egyike kideríteni, így pontosan ezért nem értem, miért is lenne érv jelen esetben az, hogy "nem biztos, hogy fogod tudni, a kivételedet hol dobod" - dehogynem, pontosan fogom tudni: lásd pl. getFile(), getLine(), getTrace() vagy épp getTraceAsString() függvények...Régen, mielőtt a kivételkezelést egyáltalán alkalmaztam volna, pontosan az volt a bajom, hogy sok esetben nehezen visszakövethető, hogy konkrétan hol is történt a hiba, és milyen jellegű is volt. Most meg pl. ránézek a naplóra, és egész pontosan meg tudom nézni, hol és mi is történt, valamint a kivétel mikor keletkezett.
"Ha az osztályodat majd újra fel akarod használni, nem szabad megfeledkezni arról, hogy milyen kivételeket dobhat. Amíg jól van dokumentálva a kódod, addig nem biztos, hogy fejtörést fog okozni, de ha már kevesebb időt töltesz a dokumentálással, valahol újra fel akarod használni a kódodat, szintén fogni fogod a fejed, mert fejlesztés során olyan exceptionöket fog dobálni az osztályod, amire nem számítottál korábban, és újra meg újra le kell őket kezelni. Nem is beszélve arról, hogy az exceptiönök szaporodhatnak, ahogy az osztályod egyre többet tud."
Kezdjük azzal, hogy szerintem a rossz dokumentáció egyik esetben sem segít a későbbi fejlesztésekben, ebből a szempontból teljesen lényegtelen, hogy most kivételeket dobálsz, vagy az adott esetben túlságosan is kövérre hízó, macerás if-else blokkokat alkalmazod.
Ha pedig említetted az error tömbök visszaadását: ha épp a szar dokumentáció és az újrafelhasználás a példa, akkor hogyan emlékezz vissza, hogy mi is volt a megfelelő hibakezelési mód? Pl. hogy az error tömböd milyen formában érkezik, vegyünk egy példát:
$functionReturnValue = $myClass->myMethod();
if( $functionReturnValue['status'] == FALSE ){
......
}
else {
....
}Aztán kiderül, hogy basszus, nem is $functionReturnValue['status'] a megfelelő vizsgálandó visszatérési érték indexe, hanem mondjuk $functionReturnValue['result'].
Ha viszont eldobsz egy kivételt a hiba forrásánál, az garantált, hogy itt minél előbb megtudod, hol keletkezett a hiba (pl. ha fent van egy Xdebug extension, akkor az még szép táblázatos formában ki is írja neked), és nem próbálod folytatni a programkódot a rossz visszatérési értékekkel, stb.De hogy még reagáljak arra is érdemben, hogy "olyan exceptionöket fog dobálni az osztályod, amire nem számítottál korábban, és újra meg újra le kell őket kezelni. Nem is beszélve arról, hogy az exceptiönök szaporodhatnak":
erre röviden az az egyszerű reakció, hogy ha az egész try-catch blokkod legvégére a kivételosztályok ősosztályának elkapását is elintézed, akkor nyilván nem mondok újat azzal, hogy így minden kivételt elkapsz, azt is, ami specifikusan nem volt lekezelve.
Ezeket pedig szintén naplózhatod, és akkor tudod, hogy még milyen kivétel nincs lekezelve.
Pl.:
try {
$stuff = new MyClass();
// exceptiont fogsz eldobni, mégpedig így:
// throw new MyNewException( 'asdasd' );
$stuff->myMethod();
} catch ( MyOldException $e ){
...
} catch ( AnyOtherException $e ){
...
} catch ( Exception $e ){
...
// itt elkapod a többit!!!
}Így tehát azt az esetet is lekezelted, amit előre nem láttál - a másik esetben sokkal nehezebb ennyire általános receptet adni az "egyéb" kategóriába eső hibák megfelelő kezelésére és naplózására.
Új hozzászólás Aktív témák
- Új Honor 400 pro + 66 wattos töltőfej
- ASUS TUF Gaming A620M-Plus + AMD Ryzen 5 8400F + 16GB 5600MHz Kingston Fury Beast + hűtő
- Eladó Erős Gamer PC - Akár Cyberpunk 2077-re Is Készen! (Ryzen 3 2200G RX 570 8GB 32GB RAM AIO
- MacBook Pro 2019 '16 2,6 Ghz 6mag Intel Core i7 16/512gb - Space Gray Touch Bar
- Xiaomi 13T 256GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA! Épített KomPhone Ryzen 5 7500F 32/64GB DDR5 RTX 5060 8GB GAMER PC termékbeszámítással
- Csere-Beszámítás! Olcsó Számítógép PC Játékra! R5 1500X / RX 570 8GB / 16GB DDR4 / 250SSD + 2TB HDD
- Bomba ár! HP Elitebook 850 G3 - i7-6GEN I 16GB I 256GB SSD I RadeonI 15,6" FHD I Cam I W11 I Gari!
- Telefon felvásárlás!! Samsung Galaxy S24/Samsung Galaxy S24+/Samsung Galaxy S24 Ultra
- Telefon felvásárlás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest