[PHP] Exceptions gooien, voor error afhandeling

[bindsa]

Ik ben op het moment bezig om een applicatie om te bouwen, meer naar OOP i.p.v. naar procedureel toe. Nu wilde ik ook zorgen voor goede error afhandeling. Toen ben ik dus naar try-catch en exceptions gaan kijken. Zo kan ik exceptions gooien als er iets mis gaat, en deze met set_exception_handler afvangen. In de functie die ik als exception handler heb ingesteld kan ik dan netjes de output buffer leeggooien, en een mooie errorpagina op het scherm toveren. Werkt allemaal perfect tot nu toe. Maar nu loop ik tegen een probleem aan, bij simpele dingen lukt het me niet om exceptions te genereren. Bijvoorbeeld:

PHP:

require_once "config.php" or (throw new Exception("engine::including_files::config_file_not_found"));

Dit werkt dus niet. Ik wil dat als de file niet gevonden wordt er een exception gegooid wordt. Nou kan ik eerst met file_exists kijken of het bestand er is, als ie er is requiren, en anders exception gooien.

Iets anders wat zou kunnen is (en qua implementatie veel makkelijker is) gewoon geen exception gooien en d.m.v. van set_error_handler("foo") en dan in foo gewoon een exceptie gooien. Die ik dan weer vang met de exception_handler. Grote nadeel daarvan is alleen dat ik geen custom error messages zoals "engine::including_files::config_file_not_found" kan meegeven.

Hoe kan ik dit soort dingen nou het handigste oplossen? (Zonder dat ik achter elk regeltje iets extra's hoef te typen)

[ Voor 6% gewijzigd door bindsa op 03-06-2010 14:49 ]

[RobIII]

Ik ben geen PHP expert maar gooit require_once niet zelf al een exceptie als het includen niet lukt?

[Face_-_LeSS]

Zomaar een ideetje hoor maar kun je niet een error_handler maken die checkt of het een include/require error was en op basis daar van een exception gooien?

[MueR]

Op require(_once) kan je niks gooien, net zo min als op include(_once). Wanneer een bestand wat vitaal is voor de uitvoering van je systeem niet bestaat, hoort je systeem keihard dood te gaan, dan moet je het uploaden.

[ Voor 6% gewijzigd door MueR op 03-06-2010 15:02 ]

[Kaasplank]

maak van wat er in je config.php staat een class en maak je eigen autoloader class die je registreert met spl_autoload_register.

Vervolgens kun je simpelweg new config(); typen die dan vanzelf je config.php aanroept. waarna je in je autoloader class met is_readable kunt kijken of het bestand bestaat en daar je eventuele exception gooien.

[ Voor 7% gewijzigd door Kaasplank op 03-06-2010 15:03 ]

[MueR]

Kaasplank:
Ja leuk, ga door allerlei hoepels springen om te kijken of je config file bestaat. Dat is nuttig wanneer je applicatie veel publiek heeft. Het is niet nuttig. Een simpele file_exists op config.php moet meer dan voldoende zijn als je al iets wil controleren.

[m33p]

Het makkelijkst is denk ik om alle errors om te zetten naar exceptions middels set_error_handler(). Hier is ook redelijk wat over te vinden (zie ook de comments op php.net) dus dat moet wel lukken ;-)

[Priet]

Je kunt het beste gebruik maken van de set_error_handler om de standaard PHP errors en warnings om te zetten naar Exceptions.

Zie: http://nl.php.net/manual/en/class.errorexception.php

PHP:

<?php
function exception_error_handler($errno, $errstr, $errfile, $errline ) {
    throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
}
set_error_handler("exception_error_handler");

/* Trigger exception */
strpos();
?>

En afvangen doe je dan met try {} catch () ipv 'or'

[Voutloos]

Een autoloader gebruiken biedt wel meer voordelen en heeft weinig met door hoepels springen te maken.

Op honderd plekken in je code file exists, include/require en exception throwen neerzetten, da's pas stom.

[bindsa]

MueR schreef op donderdag 03 juni 2010 @ 15:02:
Op require(_once) kan je niks gooien, net zo min als op include(_once). Wanneer een bestand wat vitaal is voor de uitvoering van je systeem niet bestaat, hoort je systeem keihard dood te gaan, dan moet je het uploaden.

Je hebt helemaal gelijk, maar ik dacht als ik dat nou eens afvang, dan kan ik het netjes afhandelen met een mooie errorpagina.

Kaasplank schreef op donderdag 03 juni 2010 @ 15:03:
maak van wat er in je config.php staat een class en maak je eigen autoloader class die je registreert met spl_autoload_register.

Vervolgens kun je simpelweg new config(); typen die dan vanzelf je config.php aanroept. waarna je in je autoloader class met is_readable kunt kijken of het bestand bestaat en daar je eventuele exception gooien.

Dat is misschien nog wel een idee.

MueR schreef op donderdag 03 juni 2010 @ 15:05:
Kaasplank:
Ja leuk, ga door allerlei hoepels springen om te kijken of je config file bestaat. Dat is nuttig wanneer je applicatie veel publiek heeft. Het is niet nuttig. Een simpele file_exists op config.php moet meer dan voldoende zijn als je al iets wil controleren.

Is dan de simpelste manier om te kijken of je include files bestaan call_user_func_array gebruiken met een array van filenames? Als er 1 niet gevonden is error geven, anders alles in ene klap includen. (Anders moet ik zo vaak if file exists doen)

Priet schreef op donderdag 03 juni 2010 @ 15:08:
Je kunt het beste gebruik maken van de set_error_handler om de standaard PHP errors en warnings om te zetten naar Exceptions.

Zie: http://nl.php.net/manual/en/class.errorexception.php

PHP:

<?php
function exception_error_handler($errno, $errstr, $errfile, $errline ) {
    throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
}
set_error_handler("exception_error_handler");

/* Trigger exception */
strpos();
?>

En afvangen doe je dan met try {} catch () ipv 'or'

Dat was ik ook tegengekomen, m'n enige bezwaar is dan dat ik er geen custom error messages in kan zetten. Ik toon liever gebruiksvriendelijke errors op het scherm.

[ Voor 20% gewijzigd door bindsa op 03-06-2010 15:11 ]

[NMe]

MueR schreef op donderdag 03 juni 2010 @ 15:02:
Op require(_once) kan je niks gooien, net zo min als op include(_once). Wanneer een bestand wat vitaal is voor de uitvoering van je systeem niet bestaat, hoort je systeem keihard dood te gaan, dan moet je het uploaden.

Los daarvan is or volgens mij niet geschikt in combinatie met language constructs als require, include, die, etc. aan de linkerkant. Ze returnen namelijk stuk voor stuk niets.

PHP:

try {
  require_once "bestand.php";
}
catch (Exception $e)
{
  throw new Exception("engine::including_files::config_file_not_found");
}

Dat zou wel werken, maar die constructie is meteen wel heel erg ranzig. Dit soort exceptions horen overigens ook nooit voor te komen in je systeem dus ik zou me daar niet zo voor indekken. Als een include faalt, dan faalt doorgaans je complete applicatie toch.

offtopic:
Waarom gebruik je de generieke Exception class met een eigen message in plaats van een specifieke RequiredFileNotFoundException af te leiden van Exception en die te throwen?

L0calh0st schreef op donderdag 03 juni 2010 @ 15:09:
[...]

Dat was ik ook tegengekomen, m'n enige bezwaar is dan dat ik er geen custom error messages in kan zetten. Ik toon liever gebruiksvriendelijke errors op het scherm.

Jouw users gaan die melding nooit zien. Als een include niet aanwezig is, dan kom je dat zelf na het uploaden tegen in je live tests en/of regressietests. Jij snapt de standaard error die PHP afdrukt. Wat is het probleem?

[ Voor 18% gewijzigd door NMe op 03-06-2010 15:13 ]

[MueR]

Maar leg me nu eens uit waarom je dit wil doen? Hoe vaak gaat je config.php verdwijnen? Wat is het nut, behalve een hoop extra code en overhead. Die require_once gaat met een reden dood met een E_ERROR. Dat is de bedoeling van require: als ik hem niet kan openen, ga ik dood.

Als je perse zelf dit soort nutteloze dingen wil gaan coden, pak dan include en controleer of bepaalde defines binnen je config ook daadwerkelijk gedefined zijn. Je hebt volgens mij weer eens iets bedacht zonder na te denken over de consequenties en belangrijker het feitelijk nut, wat in deze (voor zover ik kan beoordelen op de summiere informatie) nihil is.

[bindsa]

NMe schreef op donderdag 03 juni 2010 @ 15:10:
[...]

Los daarvan is or volgens mij niet geschikt in combinatie met language constructs als require, include, die, etc. aan de linkerkant. Ze returnen namelijk stuk voor stuk niets.

PHP:

try {
  require_once "bestand.php";
}
catch (Exception $e)
{
  throw new Exception("engine::including_files::config_file_not_found");
}

Dat zou wel werken, maar die constructie is meteen wel heel erg ranzig. Dit soort exceptions horen overigens ook nooit voor te komen in je systeem dus ik zou me daar niet zo voor indekken. Als een include faalt, dan faalt doorgaans je complete applicatie toch.

offtopic:
Waarom gebruik je de generieke Exception class met een eigen message in plaats van een specifieke RequiredFileNotFoundException af te leiden van Exception en die te throwen?

Klopt dat m'n hele applicatie dan flopt, maar mijn plan was dus om dan de output buffer leeg te gooien, en een nette errorpagina aan de gebruiker te tonen.

Dat van die specifieke RequiredFileNotFoundException, snap ik geloof ik niet helemaal. Is er ergens een lijst van exceptions ofzo?

MueR schreef op donderdag 03 juni 2010 @ 15:13:
Maar leg me nu eens uit waarom je dit wil doen? Hoe vaak gaat je config.php verdwijnen? Wat is het nut, behalve een hoop extra code en overhead. Die require_once gaat met een reden dood met een E_ERROR. Dat is de bedoeling van require: als ik hem niet kan openen, ga ik dood.

Als je perse zelf dit soort nutteloze dingen wil gaan coden, pak dan include en controleer of bepaalde defines binnen je config ook daadwerkelijk gedefined zijn. Je hebt volgens mij weer eens iets bedacht zonder na te denken over de consequenties en belangrijker het feitelijk nut, wat in deze (voor zover ik kan beoordelen op de summiere informatie) nihil is.

Ik wil dit bijvoorbeeld gaan toe passen in een installatie script van een web app, daar pas ik het volgende toe. Ik zoek de config.php (telkens dirretje omhoog) en als ik niks vind dan geef ik dit weer op het scherm. Ik snap dat dat niet direct hoeft met een exception, maar ook met file_exists, ik had alleen het idee om een centrale error laag te bouwen die alles netjes toont.

[ Voor 32% gewijzigd door bindsa op 03-06-2010 15:17 ]

[MueR]

[list]• Exception De lijst met exceptions.

L0calh0st schreef op donderdag 03 juni 2010 @ 15:14:
Ik zoek de config.php (telkens dirretje omhoog) en als ik niks vind dan geef ik dit weer op het scherm.

Dat is een rare constructie. Je wil altijd vanuit je document root (of waar je applicatie ook staat) met absolute paden werken. Niet vanuit huidig zoeken tot je iets vindt. Allereerst heb je dan geen zekerheid dat je uberhaupt wel de juiste config vindt, maar dan ben je ook nog eens voor elke directory je filesystem aan het benaderen. Dat gaat lekker voor je load

[ Voor 87% gewijzigd door MueR op 03-06-2010 15:20 ]

[Priet]

L0calh0st schreef op donderdag 03 juni 2010 @ 15:09:
Dat was ik ook tegengekomen, m'n enige bezwaar is dan dat ik er geen custom error messages in kan zetten. Ik toon liever gebruiksvriendelijke errors op het scherm.

PHP:

try {
 require("config.php");
}
catch (ErrorException $e) {
  ob_clean();
  print "Oeps, config.php bestaat niet!";
}

Mooi genoeg

[NMe]

L0calh0st schreef op donderdag 03 juni 2010 @ 15:14:
[...]

Klopt dat m'n hele applicatie dan flopt, maar mijn plan was dus om dan de output buffer leeg te gooien, en een nette errorpagina aan de gebruiker te tonen.

Jouw gebruiker gaat die error nooit zien. Zo wel, dan heb jij je werk niet goed gedaan.

Dat van die specifieke RequiredFileNotFoundException, snap ik geloof ik niet helemaal. Is er ergens een lijst van exceptions ofzo?

PHP:

class RequiredFileNotFoundException extends Exception { }
class InvalidUserNameException extends Exception { }
class WhateverException extends Exception { }

PHP:

try {
  //doe alles dat je site moet doen
}
catch (RequiredFileNotFoundException $e) {
  echo 'Bestand niet gevonden';
}
catch (InvalidUserNameException $e) {
  echo 'Ongeldige gebruikersnaam';
}
catch (WhateverException $e) {
  echo 'Foo bar';
}
// catch all:
catch (Exception $e) {
  echo 'Onbekende fout';
}

[Manuel]

Ik snap ook niet waarom de E_ERROR niet genoeg gaat zijn, net zoals MueR en NMe doen. Waarom zou je zoveel overhead creëren (en moeite ervoor doen!) terwijl de normale foutmelding duidelijk genoeg is. Fouten als dat je een bestand vergeet te uploaden horen gewoon niet voor te komen als je in productie gaat/bent, dan moet het gewoon werken.

Als de gebruiker een foute handeling verricht dan kun je daar bijvoorbeeld een Exception op zetten en die leuk weergeven. Maar niet als je een bestand wilt includen.

Maar zoals je zelf ook al aangeeft, doe dit dan gewoon per file_get_contents en kijk of het bestand bestaat. Indien het bestand niet bestaat schrijf het dan weg en als het niet kan worden beschreven (of wat anders) gooi een Exception of laat de gebruiker manueel de inhoud uploaden.

[ Voor 1% gewijzigd door Manuel op 03-06-2010 15:24 . Reden: *foutje* ]

[bindsa]

MueR schreef op donderdag 03 juni 2010 @ 15:15:
[list]• Exception De lijst met exceptions.


[...]

Dat is een rare constructie. Je wil altijd vanuit je document root (of waar je applicatie ook staat) met absolute paden werken. Niet vanuit huidig zoeken tot je iets vindt. Allereerst heb je dan geen zekerheid dat je uberhaupt wel de juiste config vindt, maar dan ben je ook nog eens voor elke directory je filesystem aan het benaderen. Dat gaat lekker voor je load

Thanks voor de lijst.

Natuurlijk zit er een max aan van 5 dirs bijv. Ondertussen hoe ik bij wat de dir tot nu toe is, als config dan gevonden is, dan weet ik het path, en op basis daarvan define ik de constanten voor bijv. de include dir.

NMe schreef op donderdag 03 juni 2010 @ 15:19:
[...]

Jouw gebruiker gaat die error nooit zien. Zo wel, dan heb jij je werk niet goed gedaan.

Het gaat om een installeerbaar pakket, bij het installeren kijk ik dan of alle bendodigde bestanen aanwezig, waarna de installatie verder gaat.

[...]

PHP:

class RequiredFileNotFoundException extends Exception { }
class InvalidUserNameException extends Exception { }
class WhateverException extends Exception { }

PHP:

try {
  //doe alles dat je site moet doen
}
catch (RequiredFileNotFoundException $e) {
  echo 'Bestand niet gevonden';
}
catch (InvalidUserNameException $e) {
  echo 'Ongeldige gebruikersnaam';
}
catch (WhateverException $e) {
  echo 'Foo bar';
}
// catch all:
catch (Exception $e) {
  echo 'Onbekende fout';
}

Dat ziet er interessant uit bedankt.

[NMe]

L0calh0st schreef op donderdag 03 juni 2010 @ 15:26:
[...]

Het gaat om een installeerbaar pakket, bij het installeren kijk ik dan of alle bendodigde bestanen aanwezig, waarna de installatie verder gaat.

En je kan niet gewoon die bestanden requiren en vervolgens je eindgebruiker hoog genoeg inschatten om te bedenken "hee verrek, ik ben die files vergeten!"?

[MueR]

L0calh0st schreef op donderdag 03 juni 2010 @ 15:26:
Het gaat om een installeerbaar pakket, bij het installeren kijk ik dan of alle bendodigde bestanen aanwezig, waarna de installatie verder gaat.

Dus voor een eenmalige check ga jij een hoop extra code, overhead en I/O load veroorzaken? Je hebt toch een beginpunt van de installatie? Waarom niet file_exists?

[ Voor 3% gewijzigd door MueR op 03-06-2010 15:28 ]

[TheNephilim]

Manuel schreef op donderdag 03 juni 2010 @ 15:21:
Ik snap ook niet waarom de E_ERROR niet genoeg gaat zijn, net zoals MueR en NMe doen. Waarom zou je zoveel overhead creëren (en moeite ervoor doen!) terwijl de normale foutmelding duidelijk genoeg is. Fouten als dat je een bestand vergeet te uploaden horen gewoon niet voor te komen als je in productie gaat/bent, dan moet het gewoon werken.

Vind ik ook, bepaalde fouten wil je niet eens afvangen, die moeten gewoon niet voorkomen. Zeker bij een require van je config bestand, als dat niet werkt is er sowieso iets goed mis.

[bindsa]

MueR schreef op donderdag 03 juni 2010 @ 15:28:
[...]

Dus voor een eenmalige check ga jij een hoop extra code, overhead en I/O load veroorzaken? Je hebt toch een beginpunt van de installatie? Waarom niet file_exists?

Ik zal er een file exists van maken. Iedereen bedankt voor de vlotte reacties

[FragFrog]

MueR schreef op donderdag 03 juni 2010 @ 15:28:
[...]

Dus voor een eenmalige check ga jij een hoop extra code, overhead en I/O load veroorzaken? Je hebt toch een beginpunt van de installatie? Waarom niet file_exists?

Een custom error handler is in mijn opinie eerder een noodzaak dan een extra - zeker met sites die op productie draaien (waar error reporting gewoon uit hoort te staan). Als een SQL server op z'n smoel gaat, een gebruiker een rare datumstring invoert (DateTime gooit exceptions), door een brakke hoster readrechten ineens niet meer werken etc etc etc krijg je simpelweg exceptions. Zet je try/catch om je controller heen dan kun je als dat soort fouten echt nergens afgevangen worden (wat geheid een keer gaat gebeuren) een mooie error pagina voorschotelen inclusief eventueel een indicatie wat er fout gaat (exception.message) en bijvoorbeeld een log entry toevoegen waar die exceptie veroorzaakt werd, door wie, hoe laat, etc. En als je dat toch doet kun je net zo goed gelijk alle errors afvangen, dat is simpeler dan uitzonderingen gaan lopen maken.

Nee, normaliter is dat allemaal niet nodig, maar daarom heten die krengen ook exceptions: het zijn uitzonderingen. En een custom error handler registreren is echt geen significantie overhead, zeker als die niet gebruikt wordt.

[ Voor 4% gewijzigd door FragFrog op 03-06-2010 17:38 ]

[NMe]

FragFrog schreef op donderdag 03 juni 2010 @ 17:37:
[...]



Een custom error handler is in mijn opinie eerder een noodzaak dan een extra - zeker met sites die op productie draaien (waar error reporting gewoon uit hoort te staan). Als een SQL server op z'n smoel gaat, een gebruiker een rare datumstring invoert (DateTime gooit exceptions), door een brakke hoster readrechten ineens niet meer werken etc etc etc krijg je simpelweg exceptions. Zet je try/catch om je controller heen dan kun je als dat soort fouten echt nergens afgevangen worden (wat geheid een keer gaat gebeuren) een mooie error pagina voorschotelen inclusief eventueel een indicatie wat er fout gaat (exception.message) en bijvoorbeeld een log entry toevoegen waar die exceptie veroorzaakt werd, door wie, hoe laat, etc. En als je dat toch doet kun je net zo goed gelijk alle errors afvangen, dat is simpeler dan uitzonderingen gaan lopen maken.

Nee, normaliter is dat allemaal niet nodig, maar daarom heten die krengen ook exceptions: het zijn uitzonderingen. En een custom error handler registreren is echt geen significantie overhead, zeker als die niet gebruikt wordt.

Jij omschrijft gebruikersfouten. Je kan je daar als ontwikkelaar maar beperkt tegen indekken en voor onverwachte invoer gebruik je dan exceptions. In dit geval is het een beheersfout die ook nog eens alleen tijdens installatie optreedt. Daar kom je prima weg met de standaard PHP-error. Je hoeft niet gebruikersvriendelijk te zijn naar beheerders, die moeten juist meteen alle relevante info krijgen zonder in een log te moeten zoeken naar de exacte fout.

[MueR]

FragFrog schreef op donderdag 03 juni 2010 @ 17:37:
Nee, normaliter is dat allemaal niet nodig, maar daarom heten die krengen ook exceptions: het zijn uitzonderingen. En een custom error handler registreren is echt geen significantie overhead, zeker als die niet gebruikt wordt.

Voor dingen die error detectie mogelijk maken, prima. Een config file niet uploaden is niet een van die dingen. Daar doe je een file_exists and is_writ(e)able. Voor de rest kan je inderdaad prima exceptions gooien. Maar om voor die ene check een complete error handler te maken is overkill.

[Voutloos]

Leuk verhaal NMe en MueR. En toen werd je wakker.

[bindsa]

MueR schreef op donderdag 03 juni 2010 @ 20:49:
[...]

Voor dingen die error detectie mogelijk maken, prima. Een config file niet uploaden is niet een van die dingen. Daar doe je een file_exists and is_writ(e)able. Voor de rest kan je inderdaad prima exceptions gooien. Maar om voor die ene check een complete error handler te maken is overkill.

Misschien moet ik dit even verhelderen, die config file is niet het enige, het is het eerste voorbeeld dat ik in de code tegenkwam. Het maakt deel uit van een groter geheel, zou het inderdaad alleen om de config file gaan, dan had ik het beter anders kunnen doen. (Sorry trouwens voor het ietwat gebrekkige voorbeeld). Ik heb in ieder geval voorlopig genoeg stof tot nadenken om verder te kunnen

Offtopic: Mocht er nog iemand een goed boek over PHP zoeken, PHP 5 & MySQL het complete boek is echt een aanrader (wel een beetje prijzig, maar hij is het zeker waard)
Offtopic²: Weet iemand wat er met m'n karmagrafiek aan de hand is? Hij lijkt er sinds eind mei mee gekapt te zijn... (bindsa)

[ Voor 9% gewijzigd door bindsa op 03-06-2010 21:28 ]

[Cartman!]

Voutloos schreef op donderdag 03 juni 2010 @ 20:56:
Leuk verhaal NMe en MueR. En toen werd je wakker.

Waarom? Ik ben het eens met NMe, een config file missen is iets waar een gebruiker niks van gaat zien, hooguit de developer. Dan zet je de file neer en dan is het opgelost. Ik zou daar ook echt geen verdere handmatige controles inbouwen.

[NMe]

Voutloos schreef op donderdag 03 juni 2010 @ 20:56:
Leuk verhaal NMe en MueR. En toen werd je wakker.

Het zal vast een beetje persoonlijk zijn, maar ik zou dat soort errormeldingen vooral niet te zwaar verdoezelen. Zo'n breaking bug mag best goed en hard opvallen, dan zie je hem als beheerder tenminste meteen.

[bindsa]

NMe schreef op donderdag 03 juni 2010 @ 21:45:
[...]

Het zal vast een beetje persoonlijk zijn, maar ik zou dat soort errormeldingen vooral niet te zwaar verdoezelen. Zo'n breaking bug mag best goed en hard opvallen, dan zie je hem als beheerder tenminste meteen.

Daar heb je gelijk in. Ik denk dat ik het volgende ga doen, het installatie gedeelte trek ik buiten de error afhandeling laag. Voor de rest maak ik nette errorafhandeling. Lijkt mij het verstandigst

[Gomez12]

Voutloos schreef op donderdag 03 juni 2010 @ 20:56:
Leuk verhaal NMe en MueR. En toen werd je wakker.

Hoe ver wil je dan gaan?
Ik neem aan dat als je een config-file mist dat je dan wel een log bijgehouden wilt hebben, wat dan weer als de logging niet werkt, wat dan weer als de error-handling van het feit dat de logging niet werkt niet zichtbaar is etc. etc.

Er zijn gewoon enkele dingen waar je vanuit moet gaan :
Dat de apache server draait, dat php geinstalleerd is en dat er een basis is van files.

Ik ga eerder checken of apache draait / of php geinstalleerd is dan dat ik error handlers zou schrijven of mijn basis-files wel aanwezig zijn. En toch lever ik geen nagios daemons mee met mijn scripts...

[RobIII]

Voutloos schreef op donderdag 03 juni 2010 @ 20:56:
Leuk verhaal NMe en MueR. En toen werd je wakker.

Zonder onderbouwing is dit gewoon een kansloze opmerking.

PHP:

//$foo is guaranteed to be an integer...

if ($foo==0)
  echo 'Uh oh, kan niet delen door nul!';
else
  $bar = 10 / $foo;

PHP:

//$foo is guaranteed to be an integer...

if ($foo==0)
  echo 'Uh oh, kan niet delen door nul!';
else
  try {
    $bar = 10 / $foo;
  } catch (Exception $ex) {
    echo 'Uh oh! This shouldn\'t happen! $foo Unexpectedly changed between statements! Oh noes!';
  }

Dat is waar 't op neer komt IMHO in dit topic. Exceptions gebruik je, inderdaad, om uitzonderingen te vangen; maar wel uitzonderingen die ook af te handelen zijn. Waar je iets mee kunt. Fouten die optreden vanwege een brakke installatie of die helemaal niet voor mogen komen om welke andere reden dan ook ga je niet afvangen. Dan kun je net zo goed mijn tweede voorbeeld overal gaan hanteren. En wat als de "try" een fout maakt? Misschien beter een try ... catch om de try ... catch heen!!1 De exception die TS wil vangen komt gewoon nooit voor in een correcte installatie. Wil je de (laten) installatie controleren (door het installatiescript zelf bijvoorbeeld) dan gebruik je een file_exist.

[ Voor 18% gewijzigd door RobIII op 03-06-2010 22:39 ]

[WouZz]

Waar ik nog niemand over gehoord heb is dat het na een mislukte require(_once) gewoon afgelopen is met je script. Een require gooit geen excepties oid, maar gewoon een fatal error. Na een mislukte include daarentegen krijg je wel een warning, maar gaat je interpreter vrolijk door.

[NMe]

WouZz schreef op donderdag 03 juni 2010 @ 23:27:
Waar ik nog niemand over gehoord heb is dat het na een mislukte require(_once) gewoon afgelopen is met je script. Een require gooit geen excepties oid, maar gewoon een fatal error. Na een mislukte include daarentegen krijg je wel een warning, maar gaat je interpreter vrolijk door.

Daarom roepen de mensen hierboven ook terecht dat je eerst je eigen error handler moet setten voor de try/catch-oplossingen. Include is inderdaad de makkelijke oplossing.

[ Voor 6% gewijzigd door NMe op 04-06-2010 00:07 ]

[WouZz]

NMe schreef op vrijdag 04 juni 2010 @ 00:06:
[...]

Daarom roepen de mensen hierboven ook terecht dat je eerst je eigen error handler moet setten voor de try/catch-oplossingen. Include is inderdaad de makkelijke oplossing.

Aan die eigen error handler heb je alleen niet veel bij een fatal error. Wil je het dus mooi afvangen, inderdaad custom error handling + include (of gewoon file_exists).

Ok, foutje. Er is dus nog een last resort...

[ Voor 5% gewijzigd door WouZz op 04-06-2010 00:27 ]