Je zult nu direct "undefined index" meldingen krijgen.
Fouten zoals die van de topicstarter vallen toch een beetje onder de rubriek "te weinig koffie" en kunnen door een nette werkhouding en een goed ingerichte ontwikkelomgeving eenvoudig zelf gedetecteerd + opgelost worden.
EDIT: ben je trouwens nieuwe code aan het schrijven met mysql_-functies? Ik zou je dringend willen verzoeken over te schakelen naar MySQLi of PDO want de MySQL-extensie is waarschijnlijk binnenkort definitief verdwenen. Mogelijk krijg je hier, met het inschakelen van melding + weergave van fouten, nu ook boodschappen over dat die extensie deprecated is. Of je moet een verouderde PHP-versie gebruiken.
Ik zie in bovenstaand codefragment maar 14 regels. Welke van deze regels zouden dan regel 23 en 25 moeten zijn?
De foutmeldingen zijn redelijk to-the-point. Lees goed wat er staat, dit legt meestal direct de vinger op de zere plek.
Raadpleeg ook de documentatie, in vergelijking met de oorspronkelijke MySQL extensie zijn er mogelijk parameters verschoven en/of nu verplicht.
En als je verstandig bent leer je direct werken met de object-georiënteerde aanpak en vat je je mysqli-functionaliteit in een of meer wrapper classes zodat wanneer de MySQL implementatie de volgende keer verandert je niet heel je code door hoeft te ploeteren maar in het meest ideale geval enkel de implementatie van je wrappers hoeft aan te passen. In zekere zin ben je met directe aanroepen van mysqli-functies dingen aan het hardcoden en dat is mogelijk iets dat je zou moeten vermijden.
Een wrapper voor alles inbouwen vind ik een beetje onnodig. Er zijn voorlopig nog geen plannen dat MySQLi zal worden geruimd, of als deze wordt uitgebreid zal dit vaak wel 'backward compatibility' zijn. Ook heb ik weinig gezien dat mensen van MySQL-databases overstappen naar wat anders, waar een wrapper-class weer goed voor is. Het is een beetje kosten-baten verhaal in mijn ogen en ook vooral hoe getalenteerd je bent met programmeren. Voor een grote applicatie zou ik het doen, maar voor een simpele website vind ik het overdreven.
Wel maak ik een kleinere wrapper in de vorm van een extend. Hiermee extend ik de MySQLi class en kloon de de query-method alwaar ik daar directe foutafhandeling in bouw. Uiteraard zou ik in de exceptionhandler wel controleren of men de technische foutmeldingen mag zien. Want je wilt bezoekers niet voorzien van lastige niet-relevante foutmeldingen of zelfs hackers meer wijsmaken over de bouw van je applicatie.
<?php
// Een child (extend) van de standaard mysqli klasse aanmaken.
class mysqli_extend extends mysqli
{
function query($query)
{
$result = parent::query($query)
if($this->error)
{
throw new Exception(mysqli_error($this), mysqli_errno($this));
}
return $result;
}
}
?>
<?php
$mysqli = new mysqli_extend('host', 'user', 'pass', 'database');
// voorbeeld query
$sql = "SELECT email FROM tabel WHERE naam = 'Kees'";
try {
$result = $mysqli->query($sql);
$data = $result->fetch_assoc());
print_r($data);
}
catch(Exception $e)
{
echo $e->getMessage();
}
?>
Wrappers zijn goed en wel wanneer ze een zekere meerwaarde hebben. Dat gezegd hebbende, het bovenstaande is een goed begin maar heeft wel erg weinig vlees aan de botten. Daarnaast kun je met behulp van ingebouwde functies/methoden het gedrag van (het uitvoeren van) queries al zo instellen dat er automatisch exceptions gethrowd worden bij fouten, deze code hoef je dus in principe niet zelf te schrijven.
Een wrapper zou je ook werk uit handen moeten nemen. Zo zou je dus een eigen constructor kunnen schrijven die allerlei instellingen automatisch voorziet van een standaard waarde. Zoals: de host (gebruik bij voorkeur een IP en niet "localhost" of een andere hostname), de poort (standaard 3306) en niet te vergeten (héél belangrijk, maar ontbreekt in het bovenstaande voorbeeld) een expliciete character encoding (mogelijke default: utf8). Je hoeft dan enkel afwijkende instellingswaarden op te geven bij connectie wat in de praktijk neerkomt op enkel een gebruikersnaam, wachtwoord en database-naam.
Ook kun je in een wrapper een heleboel (micro-)optimalisaties doorvoeren en functies/methoden bundelen.
Dit komt niet helemaal uit de verf in het bovenstaande (en enigszins triviale) voorbeeld.