[PHP] Non-debug assert() / if (!cond) throw shorthand

[Olaf van der Spek]

PHP:

if (!cond) // 1
  throw new Exception(''); // of die()

assure(cond); // 2

Patroon 1 kom je nogal eens tegen, maar vaak is het niet nodig de exceptie te vangen. Het type exceptie en de tekst doet er ook niet altijd toe. Is hier niets voor dat simpeler en korter is, ik zou liever patroon 2 schrijven.
Ik kan assure() natuurlijk zelf even schrijven..

[NMe]

Als je het zelf kan schrijven, wat is dan je vraag precies? Ik zou het overigens geen super design vinden, het is voor mensen die het lezen niet per se duidelijk wat die functie dan doet. Dan liever die ene regel extra code.

[Voor 58% gewijzigd door NMe op 07-10-2018 13:39]

[Spinal]

assert kan een Exception geven als je het goed instelt.

[Olaf van der Spek]

NMe schreef op zondag 7 oktober 2018 @ 13:38:
Als je het zelf kan schrijven, wat is dan je vraag precies?

Of er een standaard PHP functie is en/of dit op een andere / betere manier kan.

Ik zou het overigens geen super design vinden, het is voor mensen die het lezen niet per se duidelijk wat die functie dan doet.

Omdat het non-standard is? Lijkt best op assert() toch?

Spinal schreef op maandag 8 oktober 2018 @ 10:23:
assert kan een Exception geven als je het goed instelt.

Assert is bedoelt voor debug-only checks.

[Voor 26% gewijzigd door Olaf van der Spek op 09-10-2018 15:39]

[NMe]

Olaf van der Spek schreef op dinsdag 9 oktober 2018 @ 15:22:
[...]

Of er een standaard PHP functie is en/of dit op een andere / betere manier kan.

Er is geen standaardfunctie voor. De betere manier is om gewoon duidelijk in je code te hebben staan wat het doet, met als bijkomend voordeel dat je zelf kan bepalen welke exception je wil gooien voor elke specifieke check.

Omdat het non-standard is? Lijkt best op assert() toch?

Het heeft inderdaad 5 van de 6 letters waarvan 4 zelfs op dezelfde plek, maar daar houdt 't wel zo'n beetje mee op. Het punt van assertions is dat je die exceptions niet afvangt, dat doet PHPUnit wel voor je. Je hebt dus ook geen verschillende soorten exceptions nodig.

Je bedoelt trouwens, "ensure," "assure" is iets anders.

[XyritZz]

Je zou deze library kunnen gebruiken: https://github.com/webmozart/assert

Is vrij populair, en vind het zelf duidelijker dan zelf de volledige conditie schrijven en met een custom functie evaluaten of het true is.

[.oisyn]

Olaf van der Spek schreef op dinsdag 9 oktober 2018 @ 15:22:
Assert is bedoelt voor debug-only checks.

Maar wat wil je dan precies? De gebruiker met een errorpagina om z'n oren gooien? Dan kun je net zo goed wel assert gebruiken

XyritZz schreef op dinsdag 9 oktober 2018 @ 16:19:
en vind het zelf duidelijker dan zelf de volledige conditie schrijven

Je vindt Assert::isGreater($a, 5) duidelijker dan assert($a > 5)?

[Olaf van der Spek]

.oisyn schreef op dinsdag 9 oktober 2018 @ 16:29:
Maar wat wil je dan precies? De gebruiker met een errorpagina om z'n oren gooien? Dan kun je net zo goed wel assert gebruiken

Ja, maar daar is assert() niet voor bedoeld.
Werkt ook niet als zend.assertions != 1.

assert() is a language construct in PHP 7, allowing for the definition of expectations: assertions that take effect in development and testing environments, but are optimised away to have zero cost in production.

[XyritZz]

.oisyn schreef op dinsdag 9 oktober 2018 @ 16:29:
[...]

Je vindt Assert::isGreater($a, 5) duidelijker dan assert($a > 5)?

code:

Assert::nullOrString($middleName, 'The middle name must be a string or null. Got: %s');

Vind ik veel duidelijker dan

code:

if ($middleName !== null) {
 assert(is_string($middlename), new \InvalidArgumentException('...'));
}

Voor de complexere validatie zou ik absoluut een library inzetten, voor simpele voorbeelden zou ik dan voor consistentie kiezen en één validatiemethode in de gehele applicatie willen gebruiken.

[ThomasG]

Assertions zijn eigenlijk bedoelt voor het testen van o.a. een invariant in je code. Niet voor het valideren van argumenten, en zeker niet voor production exceptions. Stel je hebt een if-statement:

PHP:

if ($i % 3 == 0) {
    ...
} else if ($i % 3 == 1) {
    ...
} else { // We know ($i % 3 == 2)
    ...
}

Bij de else gaan we er van uit dat $i % 3 == 2 is. Omdat we dat niet runtime in production willen checken, gebruik je in zulke gevallen assert om in debug te testen dat onze aanname dat het zo is, ook daadwerkelijk zo is. Bijv.

PHP:

if ($i % 3 == 0) {
    ...
} else if ($i % 3 == 1) {
    ...
} else {
    assert($i % 3 == 2);
    ...
}

Nu is dit een eenvoudig voorbeeld, maar er zijn gevallen waarbij het enorm handig is, en een hoop zorgen scheelt.

[foxgamer2019]

Dat wat @ThomasG zegt wil ik ook aangeven, dit hoort eigenlijk niet hier thuis.
Als ik kijk naar Lavarel dan lossen ze dit mooi op door een Request te gebruiken, deze heeft dan ook de juiste response terug afhankelijk van de middleware.

Zelf probeer ik dus te valideren vóór de controller actie.

[CH4OS]

XyritZz schreef op dinsdag 9 oktober 2018 @ 16:48:
[...]

code:

Assert::nullOrString($middleName, 'The middle name must be a string or null. Got: %s');

Vind ik veel duidelijker dan

code:

if ($middleName !== null) {
 assert(is_string($middlename), new \InvalidArgumentException('...'));
}

Voor de complexere validatie zou ik absoluut een library inzetten, voor simpele voorbeelden zou ik dan voor consistentie kiezen en één validatiemethode in de gehele applicatie willen gebruiken.

Ik ben dan toch benieuwd, waarom je

PHP:

    public static function isArray($value, $message = '')
    {
        if (!is_array($value)) {
            static::reportInvalidArgument(sprintf(
                $message ?: 'Expected an array. Got: %s',
                static::typeToString($value)
            ));
        }
    }

wilt laten doorlopen, terwijl een

PHP:

if (is_array($var)) {}

Ook meer dan ruimschoots volstaat?

Ik zou dergelijke exceptions niet willen gooien, zeker naar een gebruiker niet. De gebruiker wil je gewoon een (web)pagina weergeven dat er wat fout ging. Naar jezelf mail of log je dan de foutmelding om het op te lossen. Maar ik zou zeker niet het hele script afschieten omdat een variabele niet is wat je verwacht dat het moet zijn. Dit is leuk voor unittesting, waarin dergelijke functies ook al zitten, dus wat mij betreft is deze package overbodig.

[Olaf van der Spek]

CH4OS schreef op dinsdag 9 oktober 2018 @ 17:02:
Ik zou dergelijke exceptions niet willen gooien, zeker naar een gebruiker niet. De gebruiker wil je gewoon een (web)pagina weergeven dat er wat fout ging. Naar jezelf mail of log je dan de foutmelding om het op te lossen.

Dat kan toch, als je de exceptie vangt of in een andere handler?

[CH4OS]

Olaf van der Spek schreef op dinsdag 9 oktober 2018 @ 17:37:
Dat kan toch, als je de exceptie vangt of in een andere handler?

Wat is het nut van deze library dan, dat overigens al een andere handler is, me dunkt.

Een andere handler is de genoemde class al imo, waarvan ik niet het nut zie wat het nou precies moet vergemakkelijken.

[Voor 15% gewijzigd door CH4OS op 09-10-2018 18:07]

[.oisyn]

Olaf van der Spek schreef op dinsdag 9 oktober 2018 @ 16:34:
[...]

Ja, maar daar is assert() niet voor bedoeld.
Werkt ook niet als zend.assertions != 1.

Daar is assert wél voor bedoeld, alleen jij kiest ervoor om die in productie te houden.

XyritZz schreef op dinsdag 9 oktober 2018 @ 16:48:
[...]

code:

Assert::nullOrString($middleName, 'The middle name must be a string or null. Got: %s');

Vind ik veel duidelijker dan

code:

if ($middleName !== null) {
 assert(is_string($middlename), new \InvalidArgumentException('...'));
}

Ja, no shit, maar dan ga je expres moeilijk zitten doen . Waarom is dat voorbeeld duidelijker dan

PHP:

assert($middlename === null || is_string($middlename), ...)

Of desnoods

PHP:

assert(nullOrString($middlename), ...);

Die exception gooien doe je natuurlijk gewoon in je assert handler. Punt is dat complexe asserts niet mogelijk lijken te zijn met die library.

[Voor 12% gewijzigd door .oisyn op 09-10-2018 18:46]

[XyritZz]

Olaf van der Spek schreef op dinsdag 9 oktober 2018 @ 17:37:
[...]

Dat kan toch, als je de exceptie vangt of in een andere handler?

Precies,

Ik heb die Assertion library regelmatig gebruikt in domein validatie; domein objecten wil ik nooit in een invalid state hebben en in de constructor gebruik ik de Assertions omdat ik daar juist wil dat er exceptions worden gegooid als er data in het domein wordt geschoten die niet geldig is volgens de gestelde regels van het domein.

Door de excepties in die laag gewoon te laten ontstaan kan ik het domein heel eenvoudig unit testen. Edge cases die de klant meldt is simpelweg de constructor van een domein object aanroepen en ofwel valideren dat ik een geldig object krijg, ofwel valideren dat er een InvalidArgumentException wordt gegooid.

Dat de bezoeker er via het web front-end niet mee geconfronteerd wordt is dan van een andere orde. Daar heb ik eerst client side validatie in Javascript, en vervolgens nog server side validatie in de formulier handlers. Als de bezoeker daar doorheen komt wordt alle data richting het domein gestuurd, wat op dat moment wel valid zal zijn, tenzij ik m'n werk niet goed gedaan heb en de formvalidatie niet op orde heb.

Mocht ik een fout laten ontstaan in het domein, dan is het juist de bedoeling dat de applicatie finaal onderuit gaat. De door de Assertion library gegooide InvalidArgumentException wordt pas opgevangen in de generieke ExceptionHandler van het front-end die een standaard "Oeps, er is iets fout gegaan" pagina zal tonen.

[CH4OS]

XyritZz schreef op dinsdag 9 oktober 2018 @ 23:06:
Precies,

Ik heb die Assertion library regelmatig gebruikt in domein validatie; domein objecten wil ik nooit in een invalid state hebben en in de constructor gebruik ik de Assertions omdat ik daar juist wil dat er exceptions worden gegooid als er data in het domein wordt geschoten die niet geldig is volgens de gestelde regels van het domein.

Met andere woorden, je plakt een pleister omdat de (input-)validatie niet deugd bij aanmaken van het object / model. Overigens heeft die library soms ook wel lelijke (default) exception messages, zoals bijvoorbeeld

The "%s" assertion is deprecated. You should stop using it, as it will soon be removed in 2.0 version. Use "isIterable" or "isInstanceOf" instead.

Zomaar ervan uitgaan dat de volgende versie 2.0 is. Natuurlijk, je kan een custom message meegeven, maar return dan gewoon een eigen (custom) exception met een eigen error message ipv een (te) generieke te gooien.

En de valueToString($var)-functie vind ik ook wat raar in een library wat eigenlijk alleen tests/asserts doet. De checks er in overigens ook. En de typeToString()-functie doet niet wat het zegt (kan ook niet, overigens). Ook zet het soms pas een variabele in een if-statement, het kan, maar netjes is het zeker niet, vind ik.

[Voor 45% gewijzigd door CH4OS op 10-10-2018 09:06]

[ThomasG]

XyritZz schreef op dinsdag 9 oktober 2018 @ 23:06:
[...]


Precies,

Ik heb die Assertion library regelmatig gebruikt in domein validatie; domein objecten wil ik nooit in een invalid state hebben en in de constructor gebruik ik de Assertions omdat ik daar juist wil dat er exceptions worden gegooid als er data in het domein wordt geschoten die niet geldig is volgens de gestelde regels van het domein.

Door de excepties in die laag gewoon te laten ontstaan kan ik het domein heel eenvoudig unit testen. Edge cases die de klant meldt is simpelweg de constructor van een domein object aanroepen en ofwel valideren dat ik een geldig object krijg, ofwel valideren dat er een InvalidArgumentException wordt gegooid.

Dat de bezoeker er via het web front-end niet mee geconfronteerd wordt is dan van een andere orde. Daar heb ik eerst client side validatie in Javascript, en vervolgens nog server side validatie in de formulier handlers. Als de bezoeker daar doorheen komt wordt alle data richting het domein gestuurd, wat op dat moment wel valid zal zijn, tenzij ik m'n werk niet goed gedaan heb en de formvalidatie niet op orde heb.

Mocht ik een fout laten ontstaan in het domein, dan is het juist de bedoeling dat de applicatie finaal onderuit gaat. De door de Assertion library gegooide InvalidArgumentException wordt pas opgevangen in de generieke ExceptionHandler van het front-end die een standaard "Oeps, er is iets fout gegaan" pagina zal tonen.

Assertions zijn niet bedoelt om input te valideren. Assertions zijn een hulpmiddel voor de programmeur. Je hebt bijvoorbeeld een functie die er vanuit gaat dat je in een bepaalde state zit. In die functie kun je met met assert kijken of je ook daadwerkelijk in die state zit, zodat je het merkt als je een programmeerfout maakt zonder je weer veel tijd kwijt bent met break points, omdat je het meteen ziet. In production heb je die niet nodig, maar je kunt ze wel in je code laten staan zodat je bij een aanpassing in de toekomst niet de fout in gaat.

Jij gebruikt assertions om gebruikers invoer te valideren in domein objecten. Dat is hoe je het went of keert gewoon fout. Als je applicatie in production een IllegalStateException, IllegalArgumentException, of NullPointerException throwed heb je een programmeerfout gemaakt! En dat is niet goed te praten. Ja, je wilt gebruikers wel een nette fout pagina laten zien; maar het moet wel opgelost worden.

[.oisyn]

CH4OS schreef op woensdag 10 oktober 2018 @ 08:46:
[...]
Met andere woorden, je plakt een pleister omdat de (input-)validatie niet deugd bij aanmaken van het object / model.

Onzin. Je assert dat precondities niet worden geschonden. Het is aan de aanroepende partij om aan die precondities te voldoen. De inputvalidatie is iets dat ervoor hoort, en als die er gewoon netjes inzitten dan is er ook niets aan de hand. De assert is gewoon een extra defensie tegen slechte data die er onverhoopt toch nog doorheen komt.

[CH4OS]

@.oisyn En er dus een bug zit in de input validatie, hence mijn punt. Het model is verantwoordelijk om zichzelf valide te houden en niet de logica eromheen.

[.oisyn]

CH4OS schreef op woensdag 10 oktober 2018 @ 13:42:
@.oisyn En er dus een bug zit in de input validatie, hence mijn punt.

Bugs zijn precies datgene dat asserts proberen af te vangen. Het heet niet voor niets een assertion.

[CH4OS]

.oisyn schreef op woensdag 10 oktober 2018 @ 13:43:
Bugs zijn precies datgene dat asserts proberen af te vangen. Het heet niet voor niets een assertion.

Klopt, maar dat hoort dus in unittests, niet in de normale logica, me dunkt.

[.oisyn]

Niets mis met asserts in normale logica. Daar zijn ze voor bedoeld, en daarom kun je ze ook uitzetten .

[Voor 19% gewijzigd door .oisyn op 10-10-2018 13:59]

[McKaamos]

.oisyn schreef op woensdag 10 oktober 2018 @ 13:43:
[...]

Bugs zijn precies datgene dat asserts proberen af te vangen. Het heet niet voor niets een assertion.

Dit. Never trust user input.
Het hoeft niet eens om een bug te gaan, maar kan ook prima een bot zijn die gewoon data gaat lopen opsturen naar een API oid.
Je pagina die er voor ligt kan prima validaties bevatten en toch krijg je rotzooi binnen.

Maargoed, wat ik uit de informatie van PHP begrijp, is dat assertions niet bedoeld zijn voor checks in productie.
Zie: http://php.net/manual/en/function.assert.php

Assertions should not be used for normal runtime operations like input parameter checks. As a rule of thumb your code should always be able to work correctly if assertion checking is not activated.

Het idee is dat je de werking van je code op bepaalde kritische momenten checkt.
Niet dat je assertions gebruikt/misbruikt om input te controleren. Dat is code die je zelf zou moeten schrijven.
Assertions zouden ook meer rekenwerk vereisen en dus gebruik je ze bij voorkeur niet voor runtime checks, alleen maar in Dev/Test waar een beetje meer resource verbruik niet zo erg is.

PHP bied dan ook de mogelijkheid om je assertions in productiecode te laten staan, en dan via een switch aan of uit te zetten al naar gelang de enviroment waar de software heen gedeployed is.

CH4OS schreef op woensdag 10 oktober 2018 @ 13:57:
[...]
Klopt, maar dat hoort dus in unittests, niet in de normale logica, me dunkt.

Niet persé. Het kan prima voor een Test-env blijven staan om je Test Engineers te ondersteunen in het testproces.
En in je productie code mag het blijven staan, maar je zet het gewoon uit met een switch. Dat zou moeten zorgen dat het geen resources kost.

[Voor 13% gewijzigd door McKaamos op 10-10-2018 14:08]

[CH4OS]

.oisyn schreef op woensdag 10 oktober 2018 @ 13:58:
Niets mis met asserts in normale logica. Daar zijn ze voor bedoeld, en daarom kun je ze ook uitzetten .

Nee, zover de documentatie gaat, zijn asserts dat dus niet. WikiPedia schrijft het ook, al kun je je daarbij afvragen in hoeverre dat klopt, maar als meerdere partijen het zeggen, is de kans dat het wel klopt wel groter natuurlijk.

McKaamos schreef op woensdag 10 oktober 2018 @ 14:04:
Je pagina die er voor ligt kan prima validaties bevatten en toch krijg je rotzooi binnen.

Rotzooi zul je altijd binnen kunnen krijgen, maar als je dat vervolgens (bewust of onbewust) accepteert als valide input, dan klopt er gewoon wat niet in de validatie, dat is mijn punt meer. De logica is niet verantwoordelijk om het object / model valide te houden, dat is het object / model zelf immers.

[Voor 32% gewijzigd door CH4OS op 10-10-2018 14:10]

[.oisyn]

McKaamos schreef op woensdag 10 oktober 2018 @ 14:04:
[...]

Dit. Never trust user input.
Het hoeft niet eens om een bug te gaan, maar kan ook prima een bot zijn die gewoon data gaat lopen opsturen naar een API oid.
Je pagina die er voor ligt kan prima validaties bevatten en toch krijg je rotzooi binnen.

Maar daar zijn asserts nou juist weer niet bedoeld. Input validatie moet altijd gebeuren. Asserts zijn gewoon om consistente staat in je logic af te dwingen.

CH4OS schreef op woensdag 10 oktober 2018 @ 14:08:
[...]
Nee, zover de documentatie gaat, zijn asserts dat dus niet. WikiPedia schrijft het ook

Wees duidelijker aub, quote wat er staat . Ik ga niet de hele pagina doorlezen, op zoek naar het punt dat je probeert te maken.

[Voor 27% gewijzigd door .oisyn op 10-10-2018 14:10]

[McKaamos]

.oisyn schreef op woensdag 10 oktober 2018 @ 14:09:
[...]

Maar daar zijn asserts nou juist weer niet bedoeld. Input validatie moet altijd gebeuren. Asserts zijn gewoon om consistente staat in je logic af te dwingen.

Er zijn genoeg die het daar wel voor gebruiken, was even een voorbeeld.
Maar daar heb je zeker gelijk.

Hoe dan ook zou je (aldus PHP's mensen iig) code gewoon goed moeten werken zonder assertions.
Die heb je er in staan om het testproces te vergemakkelijken en schakel je uit in productie.

[CH4OS]

.oisyn schreef op woensdag 10 oktober 2018 @ 14:09:
Wees duidelijker aub, quote wat er staat . Ik ga niet de hele pagina doorlezen, op zoek naar het punt dat je probeert te maken.

Als je al de moeite niet neemt voor de eerste alinea (en imo dus het artikel), waarom zou ik dan direct dusdanig specifiek moeten zijn?

Maar goed;

In computer programming, an assertion is a statement that a predicate (Boolean-valued function, i.e. a true–false expression) is always true at that point in code execution. It can help a programmer read the code, help a compiler compile it, or help the program detect its own defects.

Uit de eerste alinea al.

[Voor 34% gewijzigd door CH4OS op 10-10-2018 14:12]

[.oisyn]

McKaamos schreef op woensdag 10 oktober 2018 @ 14:10:
Hoe dan ook zou je (aldus PHP's mensen iig) code gewoon goed moeten werken zonder assertions.
Die heb je er in staan om het testproces te vergemakkelijken en schakel je uit in productie.

Exact. En dat geldt niet alleen voor PHP, dat hebben ze gewoon van C overgenomen.

CH4OS schreef op woensdag 10 oktober 2018 @ 14:11:
[...]
Als je al de moeite niet neemt voor de eerste alinea, waarom zou ik dan direct dusdanig specifiek moeten zijn?

Die had ik dus gelezen, en ik las niets dat ingaat tegen wat ik bedoel, vandaar dat ik het zei
.edit: dus hoe precies gaat dat in tegen wat ik zeg? Daar staat toch niet dat je het niet in je logica mag gebruiken?

Laten we specifieker zijn, wat bedoel jij precies met "dat hoort dus niet in de logica"? De hele stelling van wikipedia is dat het er dus wel in hoort, want: "it can help a programmer read the code, help a compiler compile it, or help the program detect its own defects.". Dat kan het moeilijk doen als het er niet in staat.

Als je bedoelt dat logica er niet van afhankelijk mag zijn, dan helemaal eens. Maar dat is nog geen reden om die assert niet op te nemen in je code.

[Voor 59% gewijzigd door .oisyn op 10-10-2018 14:16]

[CH4OS]

.oisyn schreef op woensdag 10 oktober 2018 @ 14:11:
Als je bedoelt dat logica er niet van afhankelijk mag zijn, dan helemaal eens. Maar dat is nog geen reden om die assert niet op te nemen in je code.

Dit dus, inderdaad. Vond het wat lastig te verwoorden, mea culpa.

[.oisyn]

Ah ok, dan zijn we het dus gewoon eens

[Voutloos]

Wellicht ook leesvoer: https://matthiasnoback.nl...-and-assertion-libraries/
Leest wat mij betreft wat prettiger dan wiki en sluit wellicht extra goed aan op dit topic omdat dit blog PHP en DDD minded is.

Pas op: bevat meningen die overlappen met .oisyn ARggh, pagina 2 en weg is de fittie.

[Voor 7% gewijzigd door Voutloos op 10-10-2018 15:31]