Php - hibakezelés
Lehet, hogy csak figyelmetlen voltam, de nem találok választ olyan apróságra, hogy például (hangsúlyozom, például! ;) ) amikor egy fopen FALSE értékkel tér vissza, akkor voltaképp mi baja lehet?
Azt látom, hogy a try-catch nagyon sok esetben nem működik, tehát szinte minden hibát figyelni kell. De adott esetben honnan fogom megtudni, mi is okozta a hibát?
Nem akarok saját hibakezelő rutint készíteni. Így esélyem sincs?
■ Azt látom, hogy a try-catch nagyon sok esetben nem működik, tehát szinte minden hibát figyelni kell. De adott esetben honnan fogom megtudni, mi is okozta a hibát?
Nem akarok saját hibakezelő rutint készíteni. Így esélyem sincs?
Ellenőrzés
Természetesen a leglényegesebb, hogy az adott művelethez van-e jogod, és erre az is_readable és is_writeable tökéletesen alkalmasak.
Például:
Köszi, de nem véletlenül
Rengeteg olyan függvénye van a PHP-nek, ami elintézi azzal a hibajelzést, hogy FALSE értékkel tér vissza, de a hiba természetéről semmit sem mond.
Nekem meg régi mániám, hogy szeretem ha adott esetben le tudom kérdezni, mi baja volt x függvénynek.
Arról nem beszélve, hogy a hibák többségének előre történő ellenőrzése elég sok erőforrást igényel, ami általában feleslegesen lassítja a rendszert.
pl., hogy a fentinél maradjunk: fopen. "bedrótozott" elérési útvonalon lévő file-t akarok elérni vele - teszem azt logot vezetek. Felesleges minden írás előtt ellenőrizni, hogy írható-e a file, hiszen egy belőtt rendszeren csak akkor válik elérhetetlenné, ha valami komoly gáz van. Viszont ha elhasal, mégis jó lenne tudni, hogy valami javítható hibáról van-e szó vagy biztosan fatális gond van.
Cache
A bedrótozott elérési utakat ugyanúgy ellenőrizni kell, elvégre ott is fennállhat rengeteg lehetőség, ami miatt akár az egész alkalmazásod leállhat, ezért ezeket érdemes ellenőrizni, és naplózni fájlba, adatbázisba, syslog-gal, vagy syslog-ng-vel. Amennyiben a kritikus hibákról még emailt is küldesz magadnak, akkor gyorsan fel tudod deríteni a problémát. Például egy rosszul sikerült restore, merevlemez vagy fájlrendszer hiba, esetleg a fájlok feltöltésekor történt jogosultság problémákra könnyen rá lehet jönni úgy, hogy megfelelően ellenőrzöl és alkalmasint naplózol.
Az utolsó PHP hibát egyébként meglepő módon az error_get_last függvény segítségével lehet lekérdezni. Például:
Asszem, félreértettél - vagy
1. Nem győzöm hangsúlyozni, hogy a fopen csak egyetlen kiragadott példa volt, nem kizárólag rá vagyok kíváncsi, mondhatni: ez csak egy mellékszál. :)
2. Nem ellenőrzés nélküli kódot akarok. Maradva a fopen() példájánál: azt ellenőrzöm, hogy FALSE értékkel tér-e vissza, de nem akarom előre ellenőrizni minden egyes fopen előtt, hogy elérhető-e a file, olvasható-e stb. Akárhonnan nézem, ha berakok még három if-then-else-t egy fopen elé, az elég rendesen növeli a processzor igényt egy forgalmas oldal esetében, mert az interpreternek minden alkalommal át kell rágnia magát rajta. (amíg nem láttam, hogy egy rosszul megírt program a leggyorsabb Itaniumos rendszert is ki tudja fektetni, addig sem hittem abban, hogy a mai processzoroknak nem számít egy-egy plusz utasítás, azóta meg... :) )
Tehát: "bedrótozott" elérési út. Többnyre rendben van, ezért csak annyit nézek,hogy sikeres volt-e a művelet. Nincs rendben? Felőlem annyit lassul a rendszer, amennyit akar, hisz úgyis működésképtelen.
3. Köszi, végülis az error_get_last volt amit kerestem, ha minden igaz. (én valami get_error v. get_message fv.-t kerestem volna és nagyon nem találtam :) )
Akárhonnan nézem, ha berakok
Tudod, én olyan oldalakon dolgozok, ahol napi többszázezer, illetve millió oldalletöltés van, és elárulom neked, nem ezeken az az if/else tételeken fog elbukni a sebesség. Sokkal inkább az I/O rétegen fog múlni, legyen az fájlrendszer, adatbázis vagy hálózati forgalom.
Persze, van ami jobban
Nekem meg vannak olyan rigolyáim, hogy felesleges dolgokat nem szeretek beleírni a scriptjeimbe. Én még így szocializálódtam. ;)
Példánál maradva
A kivételnek elérhető (logolható) a callstackje (hívásverem?). A user kaphat egy 5xx-et és esetleg egy azonosítót, amivel a logban benne lesznek az infók. Magyarán nyoma lesz, hogy melyik sorban, milyen körülmények között fordult elő a hiba.
Az már ár/érték kérdése, hogy mennyire automatizálod a hiba lokalizálását. Magyarán beépítesz-e elé létezést és írhatóságot ellenőrző sorokat. Esetleg a fájlműveletek köré írsz egy saját wrapper réteget.
Köszi, de épp nem ez volt a
(lásd fentebb: error_get_last a megoldás - azon meg külön ki vagyok akadva, hogy a try-catch blokkok pont ezen hibákra nem működnek. :( )
PHP ilyen
Vettem észre... :) Kár volt
Kár volt előre venni a Java-t és csak utána belemászni a PHP örömeibe.
Bár számomra ez még mindig kevésbé zavaró/irritáló, mint az, hogy mekkora káosz van a függvények elnevezései körül. :(
(gondolok itt olyasmire, hogy hol van benne aláhúzás, hol nincs és hasonlók.)
keretrendszer?
vagy maradhatsz a Java vonalon.. ott még talán jobban is lehet keresni...
Egyelőre tanulmányozom a
Egyébként gyakorlatilag azt csinálom: saját "keretrendszert" írok. Megnéztem párat, de egyelőre a PHP-t és az objektum orientált gondolkodást próbálom megtanulni, nem akarok még egy tanulnivalót a nyakamba venni. PHP-t 1ébként csak azért, mert az ingyenes tárhelyeken nincs más, fizetősre meg nem fussa...
Python
herokun van lehetoseged
php beepitett fuggvenyek
hiba eseten a beepitett fuggvenyek altalaban false/null ertekkel ternek vissza (konkret fuggveny manualjat nezd meg), ezt ha levizsgalod, akkor utana a error_get_last fuggveny segitsegevel le tudod kerdezni a hibauzenetet hibakoddal.
tovabbi info itt
Tyrael