try-catch, Scope Resolution Operator
- try-catch blok. Wanneer gebruik je dit nu precies wel en wanneer niet. Ik gebruik het bv. Bij een connectie op te zetten. Vervolgens heb ik het ook toegepast in de pagina zelf, niet alleen bij de query’s maar ook de html zelf heb ik in de try opgenomen. Is dit correct of overdone? Try/catch op zich ken ik wel uit de java hoek maar gaat mij wanneer/hoe zet je dit in bij website’s?
- De “Scope Resolution Operator ::”, wat is daar de gedachte achter? Je instantieert niet een klasse zodat je een object hebt, maar toch kun je een method van die klasse benaderen? Dat vind ik overigens op zich al raar, je instantieert niet een klasse –een object ‘leeft’ niet, en toch kun je een method benaderen van die klasse? Hoe kan dat zo-wie-zo?
- En wat is beter of nee, wat is gebruikelijker Ik heb gisteren een verbinding gemaakt met een Oracle database via pdo en de oci driver. Maar de ene heb ik via “include ‘include/config.php’;” procedureel gemaakt en de PDO dmv een class DBOraCon aan te maken en die te instantiëren. Beide werken maar wat is beter, gebruikelijker evt. veiliger via een include of via een klasse te instantiëren?
Het kan natuurlijk allemaal, het werkt maar dit zijn zo van de principiële/elementaire zaken die ik mij afvraag en niet echt een antwoord op kan vinden via google. Ik pas mn. het 1e en laatste punt toe, maar ik weet niet goed of ik het op een juiste manier gebruik.
Quote:
try-catch blok. Wanneer gebruik je dit nu precies wel en wanneer niet.
Je past zo'n blok toe op elke plek waar je een fout wilt opvangen. Sommige fouten worden meteen opgevangen, andere borrelen een paar klassen omhoog en worden dan pas opgevangen. Uit eindelijk heb je vaak ook nog een try-catch blok over de hele pagina staan, om elk nog niet opgevangen exception alsnog op te vangen. Erwin heeft al eens mooie voorbeelden hierover geplaatst:
Erwin H:
voorbeeld 1: je hebt een request class die alle user parameters inleest en controleert. Tijdens een check merk je dat de parameter een string is en geen integer. De request class gooit een exception om hiervan melding te maken. De class zelf vangt die direct weer af, want bij een foute invoer geef je gewoon een default waarde terug. De rest van de applicatie merkt hier dus helemaal niets van. Die krijgt gewoon een correcte waarde terug waarmee verder kan worden gegaan.
voorbeeld 2: je hebt een query in je database waarvoor je bepaalde parameters absoluut nodig hebt. Nu blijkt in de method waarin je de query wilt uitvoeren dat een parameter geen correcte waarde heeft. Hier kan je dan een exception gooien, want de query kan niet worden uitgevoerd. De aanroepende class vangt die op en bepaalt dat er dan maar een lege resultset teruggestuurd wordt. De rest van je applicatie kan gewoon door, maar laat alleen een 'lege' pagina zien (wat in veel omstandigheden best acceptabel kan zijn).
voorbeeld 3: je database connectie werkt niet. Hier laat je de database class ook een exception gooien. Dit kan de database class zelf niet verder afhandelen. De aanroepende class ook niet, want dit heeft meer gevolgen dan alleen een lege pagina (bijvoorbeeld je kan een gebruiker ook niet inloggen, je kan geen pageviews registreren etc etc). Deze exception borrelt dus helemaal op naar de applicatie/controller class die dan bepaalt dat er een specifieke foutpagina moet worden getoond.
(bron)
voorbeeld 2: je hebt een query in je database waarvoor je bepaalde parameters absoluut nodig hebt. Nu blijkt in de method waarin je de query wilt uitvoeren dat een parameter geen correcte waarde heeft. Hier kan je dan een exception gooien, want de query kan niet worden uitgevoerd. De aanroepende class vangt die op en bepaalt dat er dan maar een lege resultset teruggestuurd wordt. De rest van je applicatie kan gewoon door, maar laat alleen een 'lege' pagina zien (wat in veel omstandigheden best acceptabel kan zijn).
voorbeeld 3: je database connectie werkt niet. Hier laat je de database class ook een exception gooien. Dit kan de database class zelf niet verder afhandelen. De aanroepende class ook niet, want dit heeft meer gevolgen dan alleen een lege pagina (bijvoorbeeld je kan een gebruiker ook niet inloggen, je kan geen pageviews registreren etc etc). Deze exception borrelt dus helemaal op naar de applicatie/controller class die dan bepaalt dat er een specifieke foutpagina moet worden getoond.
(bron)
Quote:
De “Scope Resolution Operator ::”, wat is daar de gedachte achter?
Die gebruik je bij static methods. Static methods zijn geen methods die behoren tot een object, maar gewoon worden ingebouwd in een klasse. Als je een klasse hebt met alleen maar static methods heb je dus geen object, maar gewoon een leuke groep van functies.
In praktijk is een static method een ding die je vaak wilt vermijden, dat is in elk geval mijn mening. De enige reden waarin ik hem handig vind is met een Factory:
Code (php)
Quote:
En wat is beter of nee, wat is gebruikelijker Ik heb gisteren een verbinding gemaakt met een Oracle database via pdo en de oci driver.
Ik geef altijd de voorkeur aan objecten boven procedurele code, al kan functionele code ook erg mooi zijn. Het is meer je eigen smaak, maar goede OO zorgt voor een flexibelere werkomgeving.
Dat lijkt me voor een groot deel kwestie van smaak.
Voorbeeld:
Ik heb al gemerkt dat scripters met een Java verleden graag errors throwen.
Neem nu de mysql_ functies ...
Elk van die functies geeft je iets terug: recources ( _query() ), array's ( _fetch_array() )
ofwel krijg je een false terug wanneer er iets fout loopt.
Je kan dus perfect met een aantal if()'s werken. Je hoeft geen fouten te gooien. Geen enkele! Waarom doen sommige het toch? You tell me.
---
Ik heb een C verleden.
In de C-talen is het heel strikt; voorbeeld: gebruiken van eigenschappen:
- eigenschappen moet je eerst declareren; buiten elke methode. Het is strikt verboden daar al een waarde toe te kennen.
- in de constructor kan je de eigenschappen een initiële waarde geven (eventueel groepeer je dit in een init() methode). Het is strikt verboden nieuwe eigenschappen te declareren binnen een methode.
- Probeer maar eens een variabele/eigenschap te lezen als die niet eerst gedeclareerd is geweest (die code compileert niet eens) of vooraleer die een initiële waarde heeft gekregen (dit geeft een runtime error).
Code (php)
1
2
3
4
5
6
7
8
9
10
2
3
4
5
6
7
8
9
10
Class MijnKlasse {
int mijn_getal; // declareren: hier geen waarde toekennen
public:
void MijnKlasse() { // constructor
mijn_getal = 5; // initiren
};
int getGetal() {
return mijn_getal;
}
}
int mijn_getal; // declareren: hier geen waarde toekennen
public:
void MijnKlasse() { // constructor
mijn_getal = 5; // initiren
};
int getGetal() {
return mijn_getal;
}
}
Geen enkele van die verplichtingen/verboden gelden bij php (een warning of notice is geen error).
Ik ben geneigd om deze principes mee te nemen naar php. Waarom? Als ze mij om verantwoording vragen, kan ik niet zoveel meer zeggen dan 'lijkt me proper', of 'nostalgie'.
---
Ik denk dat dit een zinnig voorbeeld is van try/catch
http://www.phphulp.nl/php/forum/topic/pdoapi-en-prepared-statements-werkt-bij-mij-niet/87947/2/#630689
Gewijzigd op 03/12/2012 19:53:26 door Kris Peeters
Ik ben overigens wel een groot voorstander van exceptions, en ik hoop dat PHP heel snel stopt met die domme warnings en notices.
Quote:
Ik ben overigens wel een groot voorstander van exceptions, en ik hoop dat PHP heel snel stopt met die domme warnings en notices.
+1 Gewoon alle errors omzetten in exceptions.
Behalve parse errors