ugrás a tartalomhoz

Hibakezelés; Notice típusú "hibákkal" mennyire érdemes foglalkozni?

Anonymous · 2006. Május. 9. (K), 02.02
GET, SESSION és COOKIE változókra dobálja a Notice típusú figyelmeztetőket, meg persze egyéb esetekben is (be nem állított konstans például, de most nem ez a lényeg). Ezekkel mit lehet kezdeni? Bizonyos esetekben nem definiálhatom előre ezeket a változókat, például ha pont egy SESSION változó értékének beállítottságát akarom csekkolni, akkor ugye nem túl szerencsés, ha előre adok értéket neki csak a notice miatt...

<?php

error_reporting(E_ALL);

if ($_GET["get_var"]) {

	echo $_GET["get_var"];

}

?>
Notice: Undefined index: get_var in ...\www\teszt\index.php on line 5

Ezeknek a figyelmeztetéseknek tényleg nincs értelme, sőt, egyenesen hiba ezeket hibának venni (főleg $_GET esetén), vagy csak én látom így ezt a dolgot? Ilyenek miatt vétek egy normális hibakezelő/loggolo függvényt írni, mert egy nap után megtelik egy kisebb tárhely csak a log fileal... Ha meg a notice típust kihagyom a logból, akkor kimaradnak a többi, esetleg értékes információkat hordozó megjegyzések.
Hogyan oldjátok ezt meg?
‹ ürlap küldés, adatok visszatöltése mysql_select_db rossz adatbázis esetén is le tudok kérdezni egy adott táblából ›
 ■
1

Megoldás lehet...

Anonymous · 2006. Május. 9. (K), 05.58
Én az isset() függvényt használom.
2

kezelni kell

Hodicska Gergely · 2006. Május. 9. (K), 09.18
Ez a kérdés többnyire megosztja az embereket, van aki szerint nem kell törődni ezekkel a hibákkal, van aki szerint igen. Én ez utóbbiak közé tartozom, szerintem egy tisztességes kód nem dobál notice-okat sem, ráadásul téves az a gondolat, hogy ez nem lehet programhiba, hiszen sok esetben okozhatja például egy elgépelt tömbelem, vagy valami hasonló hiba.
Kezelés nagyon egyszerű: isset, empty függvények remekül használhatóak erre a célra. Ráadásul azzal sem értek egyet, hogy feleslegesen kell többet gépelni, mivel egy rendes editor ezt megteszi helyettünk.


Felhő
3

van értelme

presidento · 2006. Május. 9. (K), 09.22
Ezeknek a figyelmeztetéseknek tényleg nincs értelme, sőt, egyenesen hiba ezeket hibának venni

Van értelme! Például ha elgépelsz egy változónevet. Csinálj olyan kódot, hogy ne legyen egyáltalán notice sem.

A @ operátor letiltja a hibákat:
if (@$v=='') { Nem volt beállítva, vagy üres sztring volt }
@include('nincs-ilyen-fajl.inc');

stb.
4

kukacoskodás veszélyes

Hodicska Gergely · 2006. Május. 9. (K), 09.43
A @ operátorral nagyon vigyázni kell, mert elég komolyan megnehezítheti egy alkalmazás hibáinak felderítését. Igazából külső erőforrásokkal kapcsolatos kódok haználata esetén javalott a használata, de ott is csak akkor, ha a hibakezelés amúgy szépen meg van oldva.


Felhő
5

@

Anonymous · 2006. Május. 9. (K), 10.24
Az addig oké, hogy a kukac miatt nem lesz on-screen hibaüznet, de ettől az error handler logja még tele lesz szemetelve. Ráadásul ahogy előttem kifejtette Gergő, a hibakeresést is megnehezíti. Az error_reporting értéke egyébként is 0 (nulla) lesz éles körülmények között biztonsági megfontolásból, csak a fejlesztés fázisban szokás E_ALL (esetleg E_ALL ^ E_NOTICE) paraméterrel használni.

A válaszokat mindenkitől köszönöm. Az isset függvényt fogom használni. Az empty nem jó; ugyanúgy kiírja a hibaüzenetet, mint az eredeti példánál.
7

user error

Hodicska Gergely · 2006. Május. 9. (K), 14.19
Az empty nem jó; ugyanúgy kiírja a hibaüzenetet

Akkor ott valamit elnéztél, tuti nem írja ki. Én szeretem használni, mert sok esetben kell azt nézni, hogy egy változó létezik-e és nem nulla-e egyszerre, és ilyenkor jól jön ez a kis függvény (illetve pontosabban nyelvi konstrukció).
<?php
	empty($foo['bar']);
?>
Felhő
8

Sry

Anonymous · 2006. Május. 9. (K), 15.24
Elnézést, figyelmetlen voltam. Az eredeti példába illesztettem be (a feltételhez), és kiírta ugyan a hibát, de immár nem az 5., hanem a 7. sorban, ami ebben a felállásban már teljesen rendben van.
6

A notice is hiba...

Anonymous · 2006. Május. 9. (K), 13.01
A notice ugyanolyan hiba mint a többi, csak ez a programozó hanyagságát jelzi.