VNC stopt er mee :(
Vermijden van de @-operator in mijn php scripts
In april 2015 was er een migratie bij mijndomein.nl naar php 4.5. Ik heb met veel zoeken naar wijzigingen op verschillende websites en ook met behulp van phphulp.nl mijn website rspp.nl weer op orde gekregen.
Op mijn pagina's heb ik gebruik gemaakt van de @-operator. Destijds zag ik al, o.a. op de site van http://stackoverflow.com/questions/1283919/detecting-error-control-operator, dat je deze operator eigenlijk niet zou moeten gebruiken. Het zit mij toch dwars dat ik dit niet kan repareren. Onderstaand statement van stack overflow heb ik op een pagina geplakt en daar een paar @-operators verwijderd, maar dat gaat niet helemaal goed. Kunt u mij misschien hiermee helpen?
Met vriendelijke groet, Margot Schuitemaker
STATEMENT VAN STACK OVERFLOW:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
2
3
4
5
6
7
8
9
10
11
12
13
14
<?php
ini_set('display_errors',0);
error_reporting(E_ALL);
function error_handler($errno, $errstr, $errfile, $errline)
{
if (error_reporting()===0) return;
else die();
}
set_error_handler('error_handler');
//This issues an error, but the handler will return and execution continues.
//Remove the at-sign and the script will die()
@file();
echo 'Execution continued, hooray.';
?>
ini_set('display_errors',0);
error_reporting(E_ALL);
function error_handler($errno, $errstr, $errfile, $errline)
{
if (error_reporting()===0) return;
else die();
}
set_error_handler('error_handler');
//This issues an error, but the handler will return and execution continues.
//Remove the at-sign and the script will die()
@file();
echo 'Execution continued, hooray.';
?>
Topic verplaatst naar juiste categorie en code tags tegevoegd.[/modedit]
Gewijzigd op 05/01/2016 19:08:54 door Bas IJzelendoorn
Haal de @'jes eens weg, en kijken eens welke foutmeldingen je dan krijgt?
Ik zou het daarom anders aanpakken. Om te beginnen kun je de error_handler() gebruiken om van PHP-fouten exceptions te maken:
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
<?php
// PHP-fouten afhandelen als exceptions
function exception_error_handler($errno, $errstr, $errfile, $errline) {
throw new \ErrorException($errstr, $errno, 1, $errfile, $errline);
}
set_error_handler('exception_error_handler', E_ALL | E_STRICT);
error_reporting(E_ALL | E_STRICT);
ini_set('display_errors', 0);
?>
// PHP-fouten afhandelen als exceptions
function exception_error_handler($errno, $errstr, $errfile, $errline) {
throw new \ErrorException($errstr, $errno, 1, $errfile, $errline);
}
set_error_handler('exception_error_handler', E_ALL | E_STRICT);
error_reporting(E_ALL | E_STRICT);
ini_set('display_errors', 0);
?>
Daarna kun je een try/catch-blok gebruiken die de fout afvangt — en liefst ook omzeilt of oplost — met een workaround:
Code (php)
1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
<?php
try {
// Hier probeer je iets dat fout kan gaan:
file();
} catch (\ErrorException $e) {
// En hier vang je de eventuele fout op als exception:
// <...>
}
?>
try {
// Hier probeer je iets dat fout kan gaan:
file();
} catch (\ErrorException $e) {
// En hier vang je de eventuele fout op als exception:
// <...>
}
?>
Margot Schuitemaker op 05/01/2016 12:33:38:
In april 2015 was er een migratie bij mijndomein.nl naar php 4.5.
Ik hoop toch echt dat je bedoelt PHP 5.4 ...
Ik ben het ermee eens dat die ook niet voor mogen komen in / geproduceerd zouden mogen worden door code, maar afhankelijk van de kwaliteit van de code stel je daarmee je foutafhandeling mogelijk te strak af?
Ook moet je om je hele applicatie dan een try-catch blok zetten, want exceptions die je niet vangt resulteren altjd in een fatal error.
Als je vooraf fouten verwacht, anticipeer je daarop. Bijvoorbeeld met een try/catch die je applicatie waar mogelijk in leven houdt. En dat doe je dus ook niet met een gehele applicatie in een try/catch, maar maak je expliciet met een gerichte try/catch voor de specifieke code waarin je die fouten verwacht.
Het is wel vooral een ontwerpbeslissing. Ik vind ook dat je eigenlijk niets in productie moet nemen dat een E_ALL niet doorstaat, maar soms kun je niet zo compromisloos principieel zijn en dan is de ErrorException een goed compromis.
Wat ik zelf trouwens meestal doe, is een PHP-fout via de ErrorException met de PSR-3 Logger Interface loggen op het DEBUG-level. Maar ook dat is een ontwerpbeslissing.
Inderdaad het is php versie 5.4
Met vriendelijke groet,
Margot Schuitemaker