[Alg] Excepties of Strings

[Verwijderd]

Hey,

We zijn bezig met een software project aan het uitwerken voor onze GPR in school en we hebben een discussie maar het is groep tegen de andere en we weten neit wat beter is en waarom.

Volgens het gelaagde model die we volgen moet een event bestaan uit een excecute en een validate methode. De validate methode controleerd de klasseinvarianten en de excecute past daarna het model aan.

Nu is er discussie hoe we moeten kijken als de validatie lukt of niet.
De ene groep zegt, smijt een exceptie op omdat er in principe geen foute data bij de validate mag raken (wordt op gui niveau al aan input controle gedaan) de andere groep gebruikt strings die "gelukt" bevat en als het niet lukt een foutboodschap bevat.

Nu moeten we onze events afwerken en willen we een houvast om te weten wat de beste, meest gebruikte manier is van werken.

Hopelijk begrijpen jullie mijn uitleg en weten jullie raad.

[RobIII]

Waarom zou je met strings werken? Je kunt die 'foutboodschap' toch ook in die exceptie meegooien? Zodoende hou je je errorhandling mooi centraal en uit de normale flow van je app. Een exceptie gooi je in uitzonderlijke gevallen (vandaar "exception", uitzondering) en dat is het geval als die foutieve data (in principe) niet in de validate method zou mogen komen.

Ga je met (magic) strings werken dan krijg je overal van die if foo(bar)=="gelukt" constructies waar je dan alsnog moet gaan checken wat er dan mislukt is etc. Maak je per uitzondering een mooie exception dan weet je meteen aan de hand van de exception wat er loos is en hoe 'ie afgehandeld moet worden. Om nog maar niet te spreken wat er gebeurt als er vandaag of morgen iemand besluit om "geslaagd", "Gelukt", "ok" of iets dergelijks terug te geven uit je method. Werk dan op z'n minst met een constante, bool danwel enum of iets dergelijks. Maar, as said, is dat waarschijnlijk geen wenselijke oplossing.

[ Voor 78% gewijzigd door RobIII op 03-03-2008 22:23 ]

[Nick_S]

Als er volgens het model geen foute validatie kan plaats vinden, zou ik heel de validate methode schrappen en in de execute excepties gooien op het moment dat er toch foute data in gekomen is. Dat is namelijk de exceptionele flow. Een validate methode die of niks returned of een exceptie vind ik niet netjes, daarvan zou ik eerder een boolean terug verwachten.

[RobIII]

Nick_S schreef op maandag 03 maart 2008 @ 20:49:
Als er volgens het model geen foute validatie kan plaats vinden, zou ik heel de validate methode schrappen

Ik neem aan dat de GUI zorgt dat de gegevens kloppen (als in; binnen de range, numeriek, juiste min/max lengte en dat soort zaken) en dat de validatie ervoor zorgt dat de gegevens compleet zijn, dat er bestaande klantnummers ingevoerd zijn etc. Dat geeft een true (alles ok) of false (er ontbreekt bijvoorbeeld iets). Als je dan zaken tegenkomt die niet kloppen (letters in een klantnummer veld) dan gooi je een exception, want dan had de GUI in de the first place nooit de validate mogen aanroepen omdat er vooraf al bekende was dat niet alles in orde is en dat de validate dus bij voorbaat al zou falen.

[ Voor 39% gewijzigd door RobIII op 03-03-2008 21:38 ]

[Nick_S]

Ik probeer m'n punt even met wat code duidelijk te maken.

Met validate en execute.

code:

try {
   if(object.validate()) {
        object.execute();
   }
} catch (DataIncorrectException die) {

}

// Code in een andere klasse, door een andere programmeur.
object.execute(); //Dus zonder validate

Zonder validate, want dat gebeurt in de execute.

code:

try {
    object.execute();
} catch (DataIncorrectException die) {

}

Voegt de validate nog wat toe vraag ik me af, aangezien de execute ook alles moet controleren. Een andere (of dezelfde) programmeur kan ook alleen de execute uitvoeren. Dit mag ook niet fout gaan.

[whoami]

strings

Werk dan ten minste met booleans of enums.

Wat je kan doen, is in bepaalde gevallen gebruik maken van het 'try/parse' pattern. (Kijk bv naar het .NET framework waar je bv de Int32.TryParse method hebt).

[Michali]

Ik ben het er ook mee eens dat validatie in principe geen exception zou mogen opgooien, behalve voor gevallen die echt exceptioneel zijn. Validatie impliceert al dat je verwacht dat er iets niet zou kunnen kloppen, dus het vinden van zo'n invalide geval is een onderdeel van je normale flow.

Je zou bijvoorbeeld een enum kunnen definieren waarin de mogelijke opties staan en dit als returnwaarde gebruiken. Dan heb je dus meer informatie dan enkel true of false.