[GP] Gebruik van exceptions

[Fristi]

kunt afhandelen, tis zo, ik kan zeggen dat da ni mag en ne gebruiker moet daar maar opvang voor verzien (ale, degene da den interface maakt).

Als die da natuurlijk niet doet en er is toch een kieke da da probeert, tjah, dan zit het vast natuurlijk

[Norfolk]

Als ge het in die functie kunt afhandelen dat die klant geen VIP plaats mag reserveren dan doet ge dat. Kunt ge dat niet afhandelen op dat moment, dan gooit ge een exception.

Maar ge kunt toch bijna alles afhandelen in die functie zelf? Het enige wagge dan moet doen is nen "if" en als het fout loopt nen "print" van wat er fout liep? of is het juist diene print dagge moet throwen?

Stel, gij organiseert feestje en om moeite te besparen gebruikt gij zo'n library om plaatsen te reserveren. En ge maakt onderscheid tussen VIP en gewone plaatsen. Ge hebt ook veel kennis van informatica en ge wilt rond die library heel die interface schrijven.
En als een klant die de gewone prijs betaalde, een VIP plaats wilt reserveren gaat gij bepaalde handelingen willen doen.

Stel, ge wilt een 'mooi' popup schermpje met de boodschap "Dit is een VIP plaats, indien je deze plaats wil reserveren, kan je nog steeds het VIP arrangement nemen. Wil je dit? <JA> <NEEN>".

Indien je in die situatie zit, wat wil je dan dat die reservatie functie doet:

- "This is not allowed" printen op de stdout?
- Exception throwen, die je kan catchen?

[racekakje]

Ik gok op het tweede

[Sebastiaan]

ok, das waar en duidelijk

[Fristi]

Oke, thanks, clear example, point is dak wel wa exceptions te weinig heb dan, en veel

[Pieter Belmans]

Of ge voorziet een methode om te kijken of dingen matchen en ge voert deze in als preconditie en gij hebt minder werk (namelijk, precondities horen gedocumenteerd te zijn en ge merkt het wel als ze failen, terwijl ge voor exception handling expliciete én specifieke afhandeling moet voorzien) én zowel compiler als run-time omgeving hebben minder werk want exception handling code zorgt voor een beetje bloating (maar dat is gezeik in de marge, de eerste reden is de belangrijkste).

[Fristi]

Eigenlijk houd Norfolk meer rekening me een ander, terwijl gij meer rekening houd met uzelf

[Pieter Belmans]

Software bestaat uit dozen. Gij maakt dozen en die moeten met elkaar samenwerken. Exceptions doorbreken de scheiding van die dozen want ze zorgen voor communicatie van een onderliggend niveau naar het bovenliggende. Dat hoort niet want je steekt dozen in dozen in dozen.

Het is een designkeuze, maar zoals Karel-Lodewijk wel 's opmerkt "gij zijt ne angstaanjagende abstraheerder" en dit is mijns inziens de juiste vorm van abstractie .

[Tom]

precondities horen gedocumenteerd te zijn en ge merkt het wel als ze failen, terwijl ge voor exception handling expliciete én specifieke afhandeling moet voorzien) én zowel compiler als run-time omgeving hebben minder werk want exception handling code zorgt voor een beetje bloating (maar dat is gezeik in de marge, de eerste reden is de belangrijkste).

Exceptions kan je evengoed mee documenteren, en asserts moet je ook expliciet voorkomen in de hogere modules. De efficientie van beiden hangt van de situatie af, in de simpelste (niet uitzonderlijke) gevallen zijn asserts overduidelijk efficienter.

Er zit een beetje een semantische waarde in (wat is uitzonderlijk, wat is efficienter, wat is beter geschikt...), je kan het voorbeeld van Kevin zowel via asserts als via exceptions gaan implementeren, hier zal qua efficientie haast geen opmerkelijk verschil in zitten. Als je tussen onze redeneringen in zit qua gedachte zit je volgens mij goed. Zolang je maar niet enkel het ene of het andere overal gebruikt.

[Norfolk]

Soms zijn er gewoon situaties waar je geen exacte precondities kunt stellen of precondities waar de gebruiker niet altijd aan kan doen, en dan zijn exceptions gewoonweg veel makkelijker.

[Pieter Belmans]

Ja, maar op zich is deze niet erg moeilijk te formuleren he .

[Shinta]

Volgens de Java code conventions mag je voor publieke methoden geen assertions gebruiken. Enkel voor private methoden. Zelfs protected methoden zijn dubieus. Publieke methoden moeten volgens die conventies bij uitzonderlijke gevallen excepties werpen.

Zo is het ook dat als je software libraries gebruikt en je een assert ziet failen, dit meestal een bug in de software (van de library) is, bij exceptions is het eerder een fout van jezelf als deze geworpen worden.

Ten slotte moeten volgens de Software Engineering assertions afgezet kunnen worden. Als je dus ooit later een product aan het ontwikkelen bent, zet je assertions aan. Is het af, dan zet je ook de assertion checkings af (zodat ze geen processing power meer innemen). Dan ga je er echter wel vanuit dat je product perfect is, want als er anders een fout optreedt weet de gebruiker echt helemaal niet wat er mis is gegaan. Je maakt het de programmeur dus erg moeilijk.

Ten slotte (dubbele ten slotte ) zijn er in C++ weinig goede assertion mechanismes en al helemaal niet in Java (deze staan per default af ...).

Conclusie (voor mij): in theorie moet je met assertions en dergelijke werken, maar in praktijk zijn exceptions zoveel gemakkelijker. Dus als je ooit in een tijdsdruk zit zal je exceptions toepassen, en waarschijnlijk dan nog op een lelijke en slechte manier. Verder zijn er soms zo'n ingewikkelde controle structuren dat assertions niet voldoen in hun huidige staat van technologie.