- Milyen okostelefont vegyek?
- iPhone topik
- Samsung Galaxy S21 Ultra - vákuumcsomagolás
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Google Pixel topik
- Samsung Galaxy S21 FE 5G - utóirat
- Samsung Galaxy A56 - megbízható középszerűség
- CMF Phone 2 Pro - a százezer forintos kérdés
- Milyen hagyományos (nem okos-) telefont vegyek?
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
Ú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
- AKCIÓ! GIGABYTE GA-Z170X-UD3 Z170 chipset alaplap garanciával hibátlan működéssel
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5800X 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- AKCIÓ! Microsoft XBOX Series S 512GB játékkonzol garanciával hibátlan működéssel
- LG 27UL500-W - 27" IPS - 3840x2160 4K - 60Hz 5ms - HDR10 - AMD FreeSync - 300 Nits - sRGB 99%
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB DDR5 RAM RX 9070 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged