VNC stopt er mee :(
Undefined index
Ik krijg de volgende melding: Notice: Undefined index: actie in /home/voslicht/public_html/verzoekserver/login/index.php on line 64
Wie weet hoe ik het op kan lossen hier onder het stukje code wat daar bij hoort.
Code (php)
1
if ($_GET['actie'] == "status")
Ben al aan het googelen geweest maar kom er nog niet uit.
Gewijzigd op 21/01/2018 19:43:15 door Ronnie Vos
Gewijzigd op 21/01/2018 20:00:46 door Nick Vledder
Nick Vledder op 21/01/2018 20:28:02:
EDIT Wss ontstaat er al een notice bij de isset. Heb je bovenstaande code getest?
EDIT: werkt idd met isset, geen notice te zien...
Gewijzigd op 21/01/2018 20:42:02 door Nick Vledder
Nick Vledder op 21/01/2018 19:59:52:
het is slechts een notice.
Dat zijn echt de grootste K-klussen die d'r zijn: een probleem opsporen in een website waarbij de originele programmeur dacht "O, het is slechts een notice". Een notice is ook een melding dat er iets "niet helemaal goed gaat" (niet conform de verwachting), en dus gewoon een fout (maar dan net iets minder - we noemen het een slordigheid). Zelf zet ik altijd error_reporting(E_ALL) en dan een set_error_handler(...) die alles gewoon naar een Exception gooit. Dan is het tenminste duidelijk dat er *iets fout gaat* (anders hobbelt PHP veels te lang door, met allemaal halve waarheden; mi het grootste nadeel van PHP)
* schuim rond mond wegvegen doet *
Code (php)
1
2
3
4
2
3
4
public function errorHandler($error_no,$message,$filename,$line_no,$context = null){
if(error_reporting()) throw new \ErrorException($message,$error_no,0,$filename,$line_no);
elseif($this->_initialized) $this->log->info($message,$filename,$line_no);
}
if(error_reporting()) throw new \ErrorException($message,$error_no,0,$filename,$line_no);
elseif($this->_initialized) $this->log->info($message,$filename,$line_no);
}
Dus een Exception als de error ook gereport mocht worden (dus niet onderdrukt met @), en anders (wel onderdrukt) een info melding in het log (dan is het in ieder geval geen show-stopper, maar wordt je er wel op geattendeerd).
Overigens is het gebruik van @ wel in sommige gevallen zinnig, namelijk als je wéét dat er dingen fout kunnen gaan, maar niet de notice/error wilt, maar tevens dat je dan vervolgens hier op acteert door middel van een (directe of indirecte) foutafhandeling. Dit moet je niet verwarren met @ als het onder-het-tapijt-veeg-symbool want daar is het dus overduidelijk niet voor bedoeld, tenzij je misschien een struisvogel bent en/of je je opvolger op voorhand haat en een miserabel leven toewenst.
Overigens gaat de constructie A && B hierboven dan goed omdat PHP zich bedient van lazy evaluation. Dit houdt in dat als je de constructie A && B hebt, en A is false, dan kan dit nooit iets opleveren wat true is (false && whatever is altijd false), en om die reden zal 'ie dus ook niet struikelen over $_GET['actie'] == 'status' (ondanks het feit dat $_GET['actie'] niet bestaat, maar daar heb je dus in het eerste deel al een controle op uitgevoerd). De inspectie van B wordt in dat geval overgeslagen. "Oh A is false, ok we zijn klaar."
(Dus nu is ook de reden waarom de isset()-constructie werkt duidelijk en bekend)
Op eenzelfde (lazy) wijze wordt bij A || B nooit B gecontroleerd als A true is, immers true || whatever is altijd true.
EDIT: en zoals wordt aangehaald in de reacties van het gelinkte topic: als er mogelijk verwarring is over wat bij elkaar hoort, gebruik dan ( haken om dingen te groeperen ).
Gewijzigd op 22/01/2018 00:22:26 door Thomas van den Heuvel
Thomas van den Heuvel op 22/01/2018 00:12:15:
Gebruik nooooooooooooooit and, behalve wellicht in SQL, en dan liefst in HOOFDLETTERS.
Onzin. Ik heb er nog nooit enig probleem mee gehad. Gebruik, indien nodig, gewoon haakjes om de volgorde van afhandelen te bepalen.
Het is een keuze. Op het moment dat je met meerdere mensen code ontwikkelt zul je hier sowieso afspraken over moeten maken.
Ik ben van mening dat je bij logische operatoren beter af bent met symbolen dan de geschreven teksten and en or, omdat er in dat geval sneller verwarring kan ontstaan met andere zaken (denk bijvoorbeeld aan namen van constanten en variabelen). En ook is dan de binding met andere operatoren anders. Haakjes helpen natuurlijk altijd. Maar die zou je dan met and en or ook in de meest triviale gevallen moeten gaan gebruiken. Dat zou niet mijn voorkeur hebben.
Zolang je maar ergens argumenten voor hebt en je hier zelf vrede mee hebt (en je anderen die met jouw code moeten werken ook kunt overtuigen wellicht) maakt het mij niet zoveel uit wat je gebruikt, maar ik vind "heb er nog nooit enig probleem mee gehad" niet zo'n sterke :p. Is zoiets als "heb nog nooit mijn autogordels omgehad en heb nog nooit een ongeluk gehad".
Heb je het voorbeeld gezien in de SO-post waar het in een triviaal geval al "mis" gaat? Of er in ieder geval iets onlogisch gebeurt? Dat zou mij niet motiveren om and en or te verkiezen boven && en ||.
Ik moet er niet aan denken dat ik een lap code zou moeten debuggen en dat er dan na een half uur zoiets uitrolt, ik zou dat probleem op voorhand uit de weg gaan door die constructie in eerste instantie niet te gebruiken.
Gewijzigd op 22/01/2018 00:38:48 door Thomas van den Heuvel
Thomas van den Heuvel op 22/01/2018 00:32:50:
"heb er nog nooit enig probleem mee gehad"
In ongeveer 35 jaar.
Thomas van den Heuvel op 22/01/2018 00:32:50:
Heb je het voorbeeld gezien in de SO-post waar het in een triviaal geval al "mis" gaat?
In al die gevallen gebruik ik altijd haakjes.
- SanThe - op 22/01/2018 00:42:20:
In ongeveer 35 jaar.
Dit klinkt als een misleidend/vals argument. Dit is ongeveer hetzelfde als zeggen "ik ben het zo gewend". Dat rechtvaardigt niet een bepaalde aanpak.
Je geeft ook zelf aan dat je dan extra haken gebruikt, of liever gezegd moet gebruiken. Lijkt mij niet erg praktisch.
Maar als je het zo wil doen, doe je ding.
Gewijzigd op 22/01/2018 00:59:43 door Thomas van den Heuvel
( of met && )
kan ook genoteerd worden als
Daarbij kun je eventueel ook nog extra filters toepassen.
Bestaat $_GET['actie'] niet, dan zal deze functie false opleveren. Ook als actie bijvoorbeeld een mailadre s moet zijn, en het niet kan zijn qua syntax, zal de functie false opleveren.
Dit is wat korter dan met isset() te werken.