dicht timmeren?
Pagina: « vorige 1 2 3 4 5 volgende »
Nee dit moet je zien als een echt fout van een programmeur. Laat die programmeur maar zijn kop stoten. Zo blijf je bezig he ;-)
Kijk maar eens naar Zend_Db_Select.
Niels
Thanks voor je reactie. Ik heb nu wel een handige class met functies met makkelijke foutafvanging als er een verkeerd type wordt ingegeven. Ik zal het niet overal implementeren maar alleen op die plekken waar het echt verkeerd kan gaan. Als iets nu per se een string moet zijn, hoef ik alleen maar te zeggen ErrorIf::notString($string); dus dat is wel handig :)
Toevoeging op 14/03/2012 21:18:24:
ik wil voorkomen dat bijv. iemand true als parameter geeft... en dat dit resulteert in 1.
Tja, wanneer iemand dat doet is dat toch zijn eigen schuld? Bij sommige situaties is het wenselijk, maar bij deze situatie zou ik het persoonlijk niet doen. Maar goed, de keus is aan jouw natuurlijk ;-)
Ozzie PHP op 14/03/2012 21:17:55:
hoe bedoel je niels?
Toevoeging op 14/03/2012 21:18:24:
ik wil voorkomen dat bijv. iemand true als parameter geeft... en dat dit resulteert in 1.
Toevoeging op 14/03/2012 21:18:24:
ik wil voorkomen dat bijv. iemand true als parameter geeft... en dat dit resulteert in 1.
Code (php)
1
if($this === $that)
Moet echt identiek zijn.
false !== 0 maar false == 0
Stel iemand vraag iets op uit een array. De key moet een string zijn, maar de verstrooide programmeur voert een boolean in. De kans bestaat dan dat hij key 1 van de array terugkrijgt. Natuurlijk is dat een stomme fout van de programmeur, maar je kan dit soort fouten wel afvangen.
Wanneer moet je nou eigenlijk fouten afvangen en wanneer niet? Is er een soort van "stelregel" aan de hand waarvan ik kan bepalen wat ik moet doen?
Naarmate ik verder ben, de deadline in zicht komt ga ik sneller programmeren en dan kom je al snel op de werkwijze van Niels. Als ik iets 'onverwachts' terug krijg dan echo of print_r ik het om te kijken wat het exact is. Als programmeur moet je wel een beetje de vaardigheid hebben om de plekken waar dingen gebeuren die je niet verwacht te onderzoeken met dit soort kleine acties.
Aan de kant van een gebruiker (informeren bij fouten), basis voor een nieuw Framework of applicatie of andere vergelijkbare dingen voor een groter publiek ga je er wellicht (voor de eindgebruiker zeker, in formulieren e.d.) wel anders mee om. Ik kan me voorstellen dat het sterk afhangt van de doelgroep en de wijze waarop met je applicatie wordt omgegaan.
Ik zal dit topic in de gaten houden, ik ben wel nieuwsgierig naar dit soort discussies die mijn kennis en kunnen verbeteren!
Fijne avond mannen!
Ik zal morgen(middag) even wat uitgebreider reageren aangezien ik nu geen tijd meer heb.
Niels
(Crispijn, leuk dat je meeleest en bedankt voor je reactie).
Teveel dicht timmeren is niet goed, maar fouten afvangen voelt ook wel lekker. Soms doe ik per ongeluk zelf iets verkeerd en als je dan een nette foutmelding krijgt die precies zegt wat er misgaat is dat ook wel lekker. Maar... waar trek je de grens?
Echt inhoudelijk is deze onderbouwing niet maar het is wel een belangrijke die wellicht uiteindelijk je uurloon kan bepalen...
Ik ben ook wel benieuwd naar de reactie van Niels!
Ozzie PHP op 14/03/2012 21:55:09:
Deadline om vanavond nog eea gereed te hebben?Zolang kan ik niet wachten Niels!!!!
Aad B op 14/03/2012 22:05:31:
Ozzie PHP op 14/03/2012 21:55:09:
Deadline om vanavond nog eea gereed te hebben?Zolang kan ik niet wachten Niels!!!!
Nee... maar ik ben er nu mee bezig :)
En als het ijzer heet is...
Je zit dus goed met je overweging als je het mij vraagt!
Maar opgegeven moment merk je dat je jezelf helemaal klem werkt en je opgesloten zit in je huis.
Nee, fouten die een developer maakt moeten gewoon de standaard foutmelding krijgen en geen eentje van jou. Een developer is als het goed is gewent aan de standaard PHP errors en zal misschien niks kunnen met jou errors.
Controle hebben over variabele en weten wat er in zit is goed, maar je kunt ook veel en veel te ver gaan met controleren.
Gewijzigd op 14/03/2012 22:53:47 door Wouter J
De vraag is als volgt:
Als je een key ophaalt, uit de registry, uit een session, uit de GET of POST waarden, uit je configuratie bestand... of waar dan ook uit... moet je er dan vanuit gaan dat op het moment dat je die key ophaalt dat die key dan ook daadwerkelijk bestaat? Kun je die verantwoordelijkheid bij een programmeur neerleggen?
Stel we hebben een configuratiebestand waar we iets uit willen halen:
Code (php)
1
2
3
4
2
3
4
<?php
$config = Registry::get('config');
$waarde = $config->waarde;
?>
$config = Registry::get('config');
$waarde = $config->waarde;
?>
Als we niet controleren of de config key bestaat zou de __get() functie er als volgt uit zien:
Mocht de $key nu niet bestaan, dan zal dit resulteren in een php warning, of (als de warnings uit staan) de code zal niet werken.
Een alternatief is: controleren of de key bestaat en een foutmelding geven als dit niet zo is:
Code (php)
Maar wat nu als de programmeur niet zeker weet of de key in de registry staat, bijvoorbeeld omdat een User pas in de registry wordt gezet als hij succesvol is ingelogd? Dan moeten we dus een exists() functie maken die controleert of de key bestaat.
Code (php)
Het bovenstaande lijkt heel mooi, maar er wordt nu 2x gecontroleerd of de key bestaat.
Is het gerechtvaardigd om de controle niet in de __get() functie te stoppen en altijd direct het resultaat terug te geven? En als onduidelijk is of de key wel of niet bestaat dat in die gevallen de exists functie wordt gebruikt? Is dat een verantwoordelijkheid die je bij de programmeur kunt neerleggen? Dat als de programmeur dan een verkeerde key ingeeft... pech gehad, er komt een foutmelding en de applicatie loopt vast?
Van de ene kant zou je kunnen zeggen dat het niet heel gebruiksvriendelijk is (ten opzichte van de programmeur), maar het scheelt wel een aantal controles dus het komt ten goede aan de performance van de applicatie. Maar de vraag is dus of je die verantwoordelijkheid bij een programmeur kunt neerleggen.
Gewijzigd op 19/03/2012 09:34:11 door Ozzie PHP
Pagina: « vorige 1 2 3 4 5 volgende »