[php] exception negeren en verder gaan

[Saven]

Hola,

Ik zit met een probleempje waar ik mee bezig ben. Een bepaalde php lib gooit een exception in het geval er iets niet bestaat. Hij gooit natuurlijk niet voor niets een exception maar het probleem is dat de rest van mijn loop niet wordt uitgevoerd.

Voorbeeld:

PHP:

try
{
    $stm = $db->query(
    "
        select blabla
    ");
    
    $results = $stm->fetchAll(PDO::FETCH_ASSOC);
    
    foreach($results as $result)
    {
        $getdata->byId($result['id']); // gooit een exception
    }
}
catch(DeException $e)
{
    print_r($e);
}

Als ik de exception niet afvang krijg ik een error dat er geen exception wordt afgevangen en gaat hij alsnog niet verder. Is het uberhaupt mogelijk om die exception te negeren en gewoon door te gaan met die foreach loop? Kom op internet alleen dingen tegen die dan je vervolg buiten het try block zetten, maar daar heb ik niet zovee aan aangezien die ById() functie elke keer wordt aangeroepen en een exception gooit..

[PatrickH89]

Dus wil je per functie call de exception afhandelen (of negeren zo je wilt). Oplossing is dan een try/catch blok binnen de foreach.

[Koppensneller]

Zo?

PHP:

    $stm = $db->query(
    "
        select blabla
    ");
    
    $results = $stm->fetchAll(PDO::FETCH_ASSOC);
    
    foreach($results as $result)
    {
                try
                {
                       $getdata->byId($result['id']); // gooit een exception
                }
                catch(DeException $e)
                {
                   print_r($e);
                 }
    }

[NMe]

Bedenk je daarbij dat je gerust mag nesten, dus je kan binnen die allesomvattende try ook nog een kleiner blokje opnemen waar je de exception opvangt en opeet en waarna je gewoon verder kan gaan.

Is er trouwens geen manier om te voorkomen dat die exception gegooid wordt? Dat zou netter zijn dan hem bewust laten gooien en opeten.

[Saven]

Ahh natuurlijk thanks guys

@NMe: nope, ik haal data op bij een specifiek id, en dat systeem geeft standaard een exception als dat id niet bestaat. Beetje gaar maarja

[PatrickH89]

Saven schreef op dinsdag 17 juni 2014 @ 13:37:

@NMe: nope, ik haal data op bij een specifiek id, en dat systeem geeft standaard een exception als dat id niet bestaat. Beetje gaar maarja

Volgens mij is daar niet zoveel gaars aan. Het kan best mogelijk zijn dat het afgehandeld moet worden als er een item met bepaald ID niet bestaat, dan is het gooien van een exception de beste oplossing.

[HuHu]

Saven schreef op dinsdag 17 juni 2014 @ 13:37:
Ahh natuurlijk thanks guys

@NMe: nope, ik haal data op bij een specifiek id, en dat systeem geeft standaard een exception als dat id niet bestaat. Beetje gaar maarja

Kun je niet van te voren controleren of het ID bestaat en zo de exception voorkomen? Bijvoorbeeld:

code:

if ($data->hasId($id)) {
  $result = #data->byId($id);
}

Of, als je SELECT query maar 0 of 1 rij terug geeft, het aantal teruggegeven rijen opvragen. Zoiets: $results->getNumRows() ?

[naam]

Kan je niet error suppression gebruiken door er een '@' voor te plakken?

[kwaakvaak_v2]

naam schreef op dinsdag 17 juni 2014 @ 16:20:
Kan je niet error suppression gebruiken door er een '@' voor te plakken?

ga jij eens heel snel je mond met veel zeep wassen.. Symptoom bestrijding is nooit de oplossing en al helemaal niet een error met @ maskeren.

[NMe]

Sowieso werkt die @ toch alleen bij errors en niet bij exceptions?

offtopic:
Overigens vind ik die @ nog wel kunnen in beperkte scopes. $var = @$_GET['var'] ?: $defaultValue; vind ik een acceptabel en zelfs leesbaarder alternatief voor $var = isset('var', $_GET) ? $_GET['var'] : $defaultValue;, mits het geen probleem is dat 0 of een lege string in $_GET['var'] dan als value niet verwerkt kan worden.

[ Voor 15% gewijzigd door NMe op 17-06-2014 16:48 ]

[cytherea]

NMe schreef op dinsdag 17 juni 2014 @ 16:46:
Overigens vind ik die @ nog wel kunnen in beperkte scopes. $var = @$_GET['var'] ?: $defaultValue; vind ik een acceptabel en zelfs leesbaarder alternatief voor $var = isset('var', $_GET) ? $_GET['var'] : $defaultValue;, mits het geen probleem is dat 0 of een lege string in $_GET['var'] dan als value niet verwerkt kan worden.

@ moet je zelfs in dit geval niet gebruiken. array_key_exists of isset is altijd beter. Als je per ongeluk een typefout maakt (bijv. $GET) kom je daar nooit achter omdat alle meldingen op die regel worden onderdrukt.

Er staat een hele mooie warning box op http://www.php.net//manual/en/language.operators.errorcontrol.php die hiervoor waarschuwt. Ook heb ik ooit eens gehoord dat met @ ervoor de hele melding wel gegenereerd wordt maar simpelweg niet getoond, dus als je heel veel notices/warnings genereerd kan dat ook een performance hit zijn. Maar daar heb ik geen bron van.

[Cartman!]

Gooi die try/catch dan in je loop.

edit: wat Koppensneller al zei dus

[ Voor 37% gewijzigd door Cartman! op 17-06-2014 21:18 ]

[ACM]

Saven schreef op dinsdag 17 juni 2014 @ 13:37:
Ahh natuurlijk thanks guys

@NMe: nope, ik haal data op bij een specifiek id, en dat systeem geeft standaard een exception als dat id niet bestaat. Beetje gaar maarja

Maar waarom vraag je dan uberhaupt data voor dat id op?

Als je dat structureel doet, kan het alsnog zijn dat je 'eerder in je code' al iets moet veranderen. Het is uiteraard mogelijk dat je bij wijze van uitzondering iets tegenkomt dat uiteindelijk toch niet blijkt te bestaan... dan is een exception opgooien (en indien nodig opvangen) prima

[TheNephilim]

cytherea schreef op dinsdag 17 juni 2014 @ 21:02:
[...]


@ moet je zelfs in dit geval niet gebruiken. array_key_exists of isset is altijd beter. Als je per ongeluk een typefout maakt (bijv. $GET) kom je daar nooit achter omdat alle meldingen op die regel worden onderdrukt.

Er staat een hele mooie warning box op http://www.php.net//manual/en/language.operators.errorcontrol.php die hiervoor waarschuwt. Ook heb ik ooit eens gehoord dat met @ ervoor de hele melding wel gegenereerd wordt maar simpelweg niet getoond, dus als je heel veel notices/warnings genereerd kan dat ook een performance hit zijn. Maar daar heb ik geen bron van.

Klopt, maar het is toch altijd een flink gesodemieter als je heel wat verschillende inputs voor een formulier moet verwerken. Zeker als sommige optioneel zijn en je dus met isset && !empty aan de slag moet

[Barryvdh]

Of gewoon een functie van maken?

PHP:

$value = Input::get('name', 'Barry'); // Laravel
$value = $this->request->get('name', $default); //Symfony
$value = get_var($key, $default); // Eigen functie?

[BoringDay]

Saven schreef op dinsdag 17 juni 2014 @ 13:27:
Hola,

Ik zit met een probleempje waar ik mee bezig ben. Een bepaalde php lib gooit een exception in het geval er iets niet bestaat. Hij gooit natuurlijk niet voor niets een exception maar het probleem is dat de rest van mijn loop niet wordt uitgevoerd.

Voorbeeld:

PHP:

try
{
    $stm = $db->query(
    "
        select blabla
    ");
    
    $results = $stm->fetchAll(PDO::FETCH_ASSOC);
    
    foreach($results as $result)
    {
        $getdata->byId($result['id']); // gooit een exception
    }
}
catch(DeException $e)
{
    print_r($e);
}

Als ik de exception niet afvang krijg ik een error dat er geen exception wordt afgevangen en gaat hij alsnog niet verder. Is het uberhaupt mogelijk om die exception te negeren en gewoon door te gaan met die foreach loop? Kom op internet alleen dingen tegen die dan je vervolg buiten het try block zetten, maar daar heb ik niet zovee aan aangezien die ById() functie elke keer wordt aangeroepen en een exception gooit..

Als je daar een exception krijgt dan gaat er iets fout en mag je niet negeren maar moet je het probleem opsporen (dus debuggen) en oplossen.

[Saven]

Ok oud topic maar ik zal het nog even kort toelichten. Het is een API en er is geen andere manier om te kijken of data bij een bepaald ID bestaat voordat die functie wordt uitgevoerd. Die zouden ze dus eigenlijk moeten maken, maarja

[ Voor 3% gewijzigd door Saven op 26-06-2014 20:32 ]

[BoringDay]

Saven schreef op donderdag 26 juni 2014 @ 20:31:
Ok oud topic maar ik zal het nog even kort toelichten. Het is een API en er is geen andere manier om te kijken of data bij een bepaald ID bestaat voordat die functie wordt uitgevoerd. Die zouden ze dus eigenlijk moeten maken, maarja

Je kan toch $result['id'] valideren voordat je $getdata->byId aanroept?
Blijkbaar is die niet assigned of een ongeldige waarde wat zeer waarschijnlijk de reden van je exception is.
Die hoor je dan ook niet te negeren, dat is een verkeerde methode.

try
... doet iets
catch {
//niks doen is een lapmiddel, geen oplossing van het probleem
}

Bij de catch dien je een vervolg actie uit te voeren want er gaat iets fout.

[ Voor 25% gewijzigd door BoringDay op 28-06-2014 12:47 ]

[Barryvdh]

Maar je exception kan ook verwacht zijn, het is niet altijd een fatale fout. Sommigen gebruiken exceptions om duidelijker aan te geven wat er fout gaat. Zo kan je een exception geven dat het record niet bestaat, of dat de data corrupt is, of dat de database niet bereikbaar is, of dat je argument ongeldig is etc. Als je die specifieke exception opvangt kan je prima gewoon verder gaan hoor.

[BoringDay]

Barryvdh schreef op zaterdag 28 juni 2014 @ 13:50:
Maar je exception kan ook verwacht zijn, het is niet altijd een fatale fout. Sommigen gebruiken exceptions om duidelijker aan te geven wat er fout gaat. Zo kan je een exception geven dat het record niet bestaat, of dat de data corrupt is, of dat de database niet bereikbaar is, of dat je argument ongeldig is etc. Als je die specifieke exception opvangt kan je prima gewoon verder gaan hoor.

Dat begrijp ik maar dan ga je geen kale try catch doen, in de catch kom je met een vervolg actie bijv. het informeren v.d. gebruiker. Zoals geen database verbinding of corrupte record is dan ook niet iets wat je moet gaan negeren daar moet je iets mee doen.

[NMe]

BoringDay schreef op zaterdag 28 juni 2014 @ 14:47:
[...]

Dat begrijp ik maar dan ga je geen kale try catch doen, in de catch kom je met een vervolg actie bijv. het informeren v.d. gebruiker. Zoals geen database verbinding of corrupte record is dan ook niet iets wat je moet gaan negeren daar moet je iets mee doen.

Soms hoef je gewoon écht niks te doen, vooral als exceptions worden gebruikt (misbruikt, IMO) om de normale flow van je applicatie af te handelen. Het voorbeeld van de topicstarter is er misschien wel zo eentje.

Als voorbeeld: ik ben momenteel zelf met een applicatie bezig waarin je reserveringen kan maken. De gebruiker heeft een dashboard waarin hij de eerstvolgende reservering gehighlight ziet worden. Stel, mijn $user->getNextReservation() zou een exception throwen wanneer er geen reservering is, dan wil ik dat afvangen en gewoon doorgaan met de flow zonder iets te doen. In mijn templatecode wordt vervolgens opgemerkt dat er geen reservering is en wordt dat blokje op een andere manier gevuld.

Nou vind ik dat zelf geen mooie manier van werken en mijn $user->getNextReservation() returnt dan ook gewoon null wanneer er geen reservering gevonden kan worden, maar de TS heeft niet de luxe om de gebruikte API te kunnen aanpassen. Grote kans dat hij dus inderdaad stilletjes wil catchen en doorgaan met de flow.

[Saven]

BoringDay schreef op zaterdag 28 juni 2014 @ 12:41:
[...]


Je kan toch $result['id'] valideren voordat je $getdata->byId aanroept?
Blijkbaar is die niet assigned of een ongeldige waarde wat zeer waarschijnlijk de reden van je exception is.
Die hoor je dan ook niet te negeren, dat is een verkeerde methode.

try
... doet iets
catch {
//niks doen is een lapmiddel, geen oplossing van het probleem
}

Bij de catch dien je een vervolg actie uit te voeren want er gaat iets fout.

nee hee want ik kan lokaal niet verifieeren of er daadwerkelijk een resultaat gekoppeld zit aan het id

NMe schreef op zaterdag 28 juni 2014 @ 15:12:
[...]

Soms hoef je gewoon écht niks te doen, vooral als exceptions worden gebruikt (misbruikt, IMO) om de normale flow van je applicatie af te handelen. Het voorbeeld van de topicstarter is er misschien wel zo eentje.

Als voorbeeld: ik ben momenteel zelf met een applicatie bezig waarin je reserveringen kan maken. De gebruiker heeft een dashboard waarin hij de eerstvolgende reservering gehighlight ziet worden. Stel, mijn $user->getNextReservation() zou een exception throwen wanneer er geen reservering is, dan wil ik dat afvangen en gewoon doorgaan met de flow zonder iets te doen. In mijn templatecode wordt vervolgens opgemerkt dat er geen reservering is en wordt dat blokje op een andere manier gevuld.

Nou vind ik dat zelf geen mooie manier van werken en mijn $user->getNextReservation() returnt dan ook gewoon null wanneer er geen reservering gevonden kan worden, maar de TS heeft niet de luxe om de gebruikte API te kunnen aanpassen. Grote kans dat hij dus inderdaad stilletjes wil catchen en doorgaan met de flow.

precies

[ Voor 46% gewijzigd door Saven op 28-06-2014 16:37 ]

[BoringDay]

Exceptions zijn juist bedoeld om te attenderen dat er iets niet klopt.
In dit geval dien je hoe dan ook $Result['id'] te valideren, als er geen resultaat is dan ga je ook niet de data met GetData opvragen.

[NMe]

Lees nou gewoon. Hij kan niet valideren of $Result['id'] al dan niet een exception zou gaan gooien zonder daadwerkelijk die exception te gooien. Hij gebruikt een of andere brakke API die een discutabel (en in mijn mening slecht) ontwerp heeft waarbij dit blijkbaar intended use is. Dan kun je tegen Saven zeggen dat het niet goed is zoveel je wil, uiteindelijk zit hij naar ik aanneem wel aan die API vast.

[Saven]

Jup, helaas

[BoringDay]

Sorry maar dit is toch puur een kwestie van debuggen?
Zoals hier eerder al door iemand aangegeven -> array_key_exists of isset
Als $Result['Id'] niet bestaat in de array item, dan kan je wel leuk try/catch erom heen gooien maar dan ben je fout aan het programmeren.

[ Voor 34% gewijzigd door BoringDay op 28-06-2014 20:49 ]

[NMe]

Nogmaals, lees nou gewoon even het topic.

$getdata->byId($result['id']); Het is niet $result['id'] welke de exception throwt, want dat kan namelijk alleen een warning of fatal error zijn, native PHP doet hier niet aan exceptions. Het is die byId-method die een exception gooit en dat is blijkbaar geen code waar Saven iets aan kan veranderen.