Gebruik van @ o.k.?
Ik ben een Opensource applicatie aan het schrijven die ook zijn eigen foutmeldingen moet gaan genereren. Om dit te realiseren moeten niet alle PHP-errors verschijnen op het beeld, als er bijvoorbeeld een MySQL-query mislukt dan moet de error niet standaard op het scherm geprint worden(wat vaak wel gebeurt). Om dit voor elkaar te krijgen zet ik @ voor de functies die geen automatische foutmelding mogen printen.
Probleem hier is dat ik ooit heb gehoord dat het slecht is om deze foutmeldingen te onderdrukken... mijn vraag is waarom? Dat zou ik graag weten voordat ik verder ga met programmeren.
Wat ook wel handig is om te zeggen is dat ik niet de PHP_errors standaard op off wil zetten
Alvast bedankt!
bijv:
if(mysqli_query($link,$query))
{
echo 'kwerie gedaan' ;
}
else
{
echo 'kweerie niet gedaan' ;
}
Gr ,
Jacco
PS: Niet om af te zeiekn, maar hoe verwacht jij een goede open source app te kunnen schrijven als je niet eens weet hoe goede foutafhandeling werkt?
Ps PS: Mischien iemand die ff het try catch princiepe ckan laten zien dat kan ik namelijk niet :P
PS Ps PS: Ben ook niet vies van een goede cursus nederlands zoals te zien is :P
Gewijzigd op 01/01/1970 01:00:00 door Jacco Engel
Het nadeel; Mocht je niet alle errors opvangen dan zijn de @'s die het lastig maken een fout in de code op te sporen, maar ook dan kan je je @'s uitsluiten als je de errors juist opvangt.
@hieronder,
Lekker boeiend, iedereen begrijpt wat ik bedoel
Gewijzigd op 01/01/1970 01:00:00 door Jacco Engel
PS
PPS
PPPS
PPPPS
Of:
PS1
PS2
PS3
PS4 (is die al uit dan? :p)
if(mysqli_query($link,$query))
{
echo 'kwerie gedaan' ;
}
else
{
echo 'kweerie niet gedaan' ;
}
komt er alsnog gewoon een foutmelding op het beeldscherm als je bijvoorbeeld met een syntax error te maken hebt. Als je het tussen try catch blokken zet dan heb je dit toch nog steeds?
@ zorgt ervoor dat je geen foutmeldingen krijgt als er bijvoorbeeld geen records zijn gevonden (ligt eraan wat je doet), of als de parameter niet juist is.
Door je eigen error_handler vang je de errors op en handel je ze op een eigen manier af.
Query niet gedaan zegt helemaal niets, wat vaak beter werkt is in een logfile (of nog handiger, log table) de mysqli_error() en de query ($query) opslaan. Dit doe je met een date/time stempel. Je kan precies zien wanneer het misging. Daarnaast kan je in een table ook heel eenvoudig kijken of dezelfde melding al een keer in de database staat. Het is een beetje jammer als iemand een meldinkje krijgt (die echo is wel prima daarvoor hoor!) en elke keer op f5 ramt dat je ook elke keer weer een nieuwe rij met die fout krijgt.
Daarnaast kan je jezelf de fout natuurlijk ook mailen, je hebt dan de weet van de fout en kan hem snel oplossen.
Lees hier alles over foutafhandeling.
Na een Try/Catch kan je ook gewoon doorgaan hoor, je kan gewoon try/catch/try/catch gebruiken. Hij springt wel uit het blok wanneer er een fout optreed. Voor 1 try/catch blok heb je vaak iets meer if/else nodig.
Ik bedoel het zo:
Code (php)
Hebben we het over hetzelfde?
Als je het volgende schrijft:
Code (php)
1
2
3
4
5
2
3
4
5
<?php
functie();
@functieaanroep($error_aanroep);
functie();
?>
functie();
@functieaanroep($error_aanroep);
functie();
?>
Dan maakt php in zijn parser van:
Code (php)
Dit doet php voor elke @ die je plaatst. En laat nu juist de ini_set een kostbare bewerking zijn binnen PHP. Daarom word het afgeraden om het niet te doen.
Bouw gewoon een eigen error handler en zorg dat je eigen functies ook die error handler gebruiken. En dan kan je die errors afhandelen zoals je zelf wilt.
Gewijzigd op 01/01/1970 01:00:00 door Joren de Wit
Om mijn verhaal nog wat gespecificeerder te maken:
http://vega.rd.no/article/php-performance-error-suppression
In principe is mijn conclusie iets verkeerd maar de feitelijke error zal een hoop vertraging opleveren.
Na nog wat onderzoek...
http://www.php.net/manual/en/language.operators.errorcontrol.php
In de eerste comment (is laatst toegevoegd) staat dit:
Quote:
taras dot dot dot di at gmail dot com
12-Aug-2008 08:29
I was confused as to what the @ symbol actually does, and after a few experiments have concluded the following:
* the error handler that is set gets called regardless of what level the error reporting is set on, or whether the statement is preceeded with @
* it is up to the error handler to impart some meaning on the different error levels. You could make your custom error handler echo all errors, even if error reporting is set to NONE.
* so what does the @ operator do? It temporarily sets the error reporting level to 0 for that line. If that line triggers an error, the error handler will still be called, but it will be called with an error level of 0
Hope this helps someone
12-Aug-2008 08:29
I was confused as to what the @ symbol actually does, and after a few experiments have concluded the following:
* the error handler that is set gets called regardless of what level the error reporting is set on, or whether the statement is preceeded with @
* it is up to the error handler to impart some meaning on the different error levels. You could make your custom error handler echo all errors, even if error reporting is set to NONE.
* so what does the @ operator do? It temporarily sets the error reporting level to 0 for that line. If that line triggers an error, the error handler will still be called, but it will be called with an error level of 0
Hope this helps someone
Misschien een ideetje om in je error_handling tutorial te integreren Blanche?
Gewijzigd op 01/01/1970 01:00:00 door Marien xD
Marien schreef op 14.01.2009 10:55:
Aha, het leek me al vrij sterk dat er ongemerkt aan de php.ini geklooid zou worden. Het gaat erom dat de error_handler onnodig aangeroepen wordt :-)In principe is mijn conclusie iets verkeerd maar de feitelijke error zal een hoop vertraging opleveren.
Quote:
Ik dacht eraan om eerst dit artikel aan te passen en wellicht dat ik dat stuk dan nog op kan nemen in de error handling handleiding.Misschien een ideetje om in je error_handling tutorial te integreren Blanche?