Beste,

Inmiddels al weer aardig wat topics gelezen en opgezocht van de beginner tot de expert. Het is alleen altijd lastig om de voor jou beste methode uit te kiezen. Ik zit momenteel namelijk met 2 problemen.

Een daarvan is de alom bekende foutafhandeling of liever gezegd het opvangen van uitzonderingen. Ik heb inmiddels begrepen dat ik in de meeste gevallen Exceptions kan gebruiken en dat ik er verstandig aan doe om meerdere catch blokken te gebruiken om zo gebruikersfouten en systeemfouten te kunnen onderscheiden.
Momenteel heb ik het zo gedaan dat mijn autoloader binnen een try blok staat. Dat houd dus in dat mocht er in een van de classes wat fout gaan, dan wordt het in ieder geval opgevangen.

Mijn punt, zodra er dus iets fout gaat stop hij al het andere wat er binnen het try blok gebeurt, zo dus ook de knoppen die ik bijvoorbeeld weer laat geven onder een error.

In een situatie als een CMS dat er geen gebruikers gevonden kunnen worden, maar ik wil er nog wel een kunnen toevoegen. Dan moet niet ineens die knop weg zijn. Zou dit inhouden dat ik dan gewoon mijn try en catch blokken anders moet doen? Of kan ik aan de hand van levels wellicht zeggen dat hij de rest gewoon uit moet voeren? Of geen exception gebruiken, maar iets totaal anders, iets van mijzelf? En de exceptions laten voor de pure fouten die alles moeten stoppen.

Mijn andere probleem ligt bij het zo min mogelijk herhalen van code. Het liefst schrijf ik het maar 1 keer. Althans dat is mijn doel.

Maar neem bijvoorbeeld mijn UserMapper, die is praktisch hetzelfde als mijn PageMapper behalve dat er een andere factory method inzit is hij gelijk. Is er geen methode om dat over te erven zonder dat mijn flexibiliteit naar de maan gaat? Denk bijvoorbeeld aan een abstracte classe?
Ozzie, nu ga je weer veel te veel in de theorie over. Ga eerst opzoek naar een praktijk voorbeeld waarin dat gebeurd. Ik ben er nog geen 1 tegen gekomen. In de OO moet je voornamelijk werken met praktijk voorbeelden, je mag niet blijven hangen in het FooBarCat wereldje.
Misschien heb je gelijk, alleen ik wil niet alles omgooien en overstappen op WAT exceptions als straks blijkt dat ik daar niet (voldoende) mee uit de voeten kan. De WAAR exceptions hebben als nadeel dat je veel dezelfde exceptions moet maken (druist in tegen het DRY princips). De WAT exceptions hebben als nadeel dat je niet exact weet WAAR de exception vandaan komt. Is het inderdaad de exception die jij denkt dat het is, of komt ie (per ongeluk) ergens vandaan waar jij het niet verwacht. Dat is nu een beetje het dubbele gevoel wat ik heb.
Even wat schematisch uitgedacht...

DBException, PageNotFoundException etc. etc.
- setError()
-- ExceptionMapper -> save

- getError()
-- ExceptionMapper -> findById /
-- ExceptionMapper -> findByDate

ExceptionMapper
- save()
-- TxtStorage -> create

- findById()
-- TxtStorage -> create

- findByDate()
-- TxtStorage -> create

- delete()

TxtStorage
- create()
- read()
- update()
- delete()

Als ik deze structuur volg, dan zou ik bijna alles met mijn exceptions kunnen doen. Ik kan het opslaan en weergeven en mocht t nodig zijn ook wissen.
De melding die de gebruiker krijg hou ik voor de view pagina, dus return ik naar mijn klasse gewoon TRUE of FALSE. Mocht de view dan een FALSE terugkrijgen geeft hij dus een simpele fout weer. Dat is immers genoeg voor de gebruiker. Ik kan er echter voor kiezen om alle fouten bij te houden in mijn database / textbestand wat ik maar wil.

Reageren