Archief - Exception throwen of boolean returnen?

Beste,

ik zit met een programmeermethode probleem. ivm functies/methods... Als je een functie/method hebt die zowiezo niks moet teruggeven kun je ervoor opteren om ofwel:

- Een boolean te retourneren die aangeeft of de functie/methode succesvol werd uitgevoerd
- of niks retourneren en bij problemen een exception throwen

Maar wat is nu het beste, bestaat hier een richtlijn voor? Wanneer ga je nu kiezen om een exception te throwen en wanneer om een bool te retouren? Bijvoorbeeld bij parameters die met null ingevuld zijn en dat niet mag, of een ongeldig pad naam, of...

Wat is nu het beste om te doen? Exceptions of bools retouren?

Ik gebruik nog vaak custom exceptions, maar dan moeten deze natuurlijk altijd correct afgehandeld worden. Indien uw exception handling niet nauwkeurig toegepast wordt, crasht uw programma ... Bij ne boolean hebt ge dat niet, maar hebt ge ook zoveel informatie niet over uw 'fout'

Het gooien en opvangen van een exception is veel duurder dan de afhandeling van een boolean. Het hangt er voornamelijk van af hoe en waar je je afhandeling wil doen of laten gebeuren.

Ik probeer alleen exceptions te gooien wanneer ik een specifieke fout moet terug geven aan een generieke functie en er een alternatieve manier bestaat om te controleren op die fout.

In het .NET framework gebeurd dat bijvoorbeeld bij de functie File.Open(). Deze gooit een FileNotFound exception wanneer het bestand niet gevonden kan worden, een andere exception wanneer er onvoldoende rechten zijn, ... Maar de File klasse heeft ook een File.Exists() functie om te kijken of het bestand al dan niet bestaat.

Een ander voorbeeld, wat het misschien duidelijker maakt is het volgende: Stel dat ik een reeks van bytes moet doorsturen naar een USB apparaat. Deze byte array moet exact 8 bytes lang zijn. Maar wanneer mijn apparaat nog niet geïnitialiseerd is of er een andere belemmering is moet ik de gebruiker ook waarschuwen. Of het sturen van het commando naar het USB apparaat gelukt is of niet handel ik dus af met een boolean. Als de reeks van byte arrays niet de correcte lengte heeft dan gooi ik daarvoor een exception en zorg ik ervoor dat die exception een geldige, localizable message returned.

Wel, je zou kunnen stellen dat men exceptions net heeft uitgevonden om de tekortkomingen van return values het hoofd te bieden.

• Als je een boolean returnt, hoe dwing je de caller dan om er effectief rekening mee te houden?
• Als je een boolean returnt, hoe kan de caller dan uitmaken wat er precies is misgelopen?
• Als je verschillende methods na elkaar aanroept die booleans teruggeven bij een fout, ga je dan de code die effectief nuttig werk levert volstoppen met if's in plaats van de foutafhandeling op een centrale plaats (het catch-block)?
• Als je method nu wel een resultaat zou teruggeven, hoe zou je dan de caller laten weten dat die method haar werk niet kan doen?

Dat gezegd zijnde: over het nut en het gebruik van exceptions bestaan er zoveel verschillende meningen dat ik vrees dat men er nog altijd niet echt uit is. Dat performantie een slechte reden is return values te verkiezen, daar zullen de meesten het dan weer wel over eens zijn.

OK, interressant! Een volgend vraagje ivm exceptions:

je hebt een method, bijvoorbeeld om een waarde uit een xml-bestand te lezen en dat te returnen. Maar, de klasse die je gebruikt om de xml-file uit te lezen throwed een exception, wat doe je daarmee? Gewoon laten doorknallen of opvangen in je method en ze als innerexception meesturen bij je custom exception?

je hebt een method, bijvoorbeeld om een waarde uit een xml-bestand te lezen en dat te returnen. Maar, de klasse die je gebruikt om de xml-file uit te lezen throwed een exception, wat doe je daarmee?

Klik om te vergroten...

Tonen + proberen te loggen, Applicatie laten crashen/stoppen

Exception = Exceptional

Hangt af hoe belangrijk die xml is voor uw programma. Als het niet al te belangrijk is en de gebruiker heeft een UI, gewoon loggen en tonen aan de gebruiker. Misschien bij een volgende poging dat het wel gaat..
Welke programmeertaal heb je voor ogen als ik vragen mag?

In java heb je bvb 2 types van exceptions. Checked en unchecked. Doorgaans is de regel: checked exceptions kan je van recoveren, unchecked exceptions zijn meestal zwaar stront aan de knikker

.NET C#

en Moto: what are you talking about?

Effective Java zei:

Exceptions are, as their name implies, to be used only for exceptional conditions; they should never be used for ordinary control flow. A well-designed API must not force its clients to use exceptions for ordinary control flow.

Klik om te vergroten...

Effective Java zei:

Use checked exceptions for recoverable conditions and runtime exceptions for programming errors.

Klik om te vergroten...

NeverwinterX zei:

Effective Java zei:

Use checked exceptions for recoverable conditions and runtime exceptions for programming errors.

Klik om te vergroten...

Klik om te vergroten...

Niet dat ik Bloch wil tegenspreken (die mens is ongetwijfeld veel slimmer dan ik) maar de method die de checked exception throwt, die kan toch zelf niet weten of het om een recoverable condition gaat?

Laat performantie in een verhaal van excepties net totaal irrelevant zijn. Op het moment dat er een uitzondering optreedt stopt de software toch vaak vroegtijdig en is er user interactie vereist. Je doet uiteraard wel best alle mogelijke aangeboden controles om excepties te vermijden, maar dat wil niet zeggen dat je code beter geen excepties gooit, integendeel. Het gooien van excepties vermijdt dat programmeurs door gebrek van kennis van een systeem te weinig controles doen en daardoor het systeem in een verkeerde toestand brengen.

Cycloon zei:

Laat performantie in een verhaal van excepties net totaal irrelevant zijn.

Klik om te vergroten...

Laat veralgemeningen in de wereld van software-ontwikkeling net totaal belachelijk zijn.

Als een systeem (ik denk in dit specifieke geval vooral aan libraries) door externen gebruikt wordt, geef je uitzonderlijke situaties inderdaad aan door exceptions te gooien.

Binnen dat systeem zijn er echter betere en performantere manieren om om te gaan met (voorzienbare) uitzonderlijke situaties dan voor het minste exceptions te gebruiken.

Er zal zeker een verschil zijn tussen exceptions en andere manieren die uiteindelijk hetzelfde doen. Maar dit is in mijn ogen afhankelijk van uw programmeerparadigma, en zou geen grote invloed mogen hebben op de performantie. Als ge de performantie wilt opdrijven zou ge naar complexiteiten van uw algoritmes moeten kijken, tenzij ge echt aan het tweaken slaat.

Volgens mij moet de gekozen aanpak gewoon logisch en consistent zijn, zodat iedereen die ooit met die code moet werken, daar gemakkelijk mee om kan. Als ge custom andere aanpakken begint te gebruiken, verliest ge tijd en moeite (of verliezen andere mensen dat) tijdens het implementeren zelf. En ik denk dat dat niet altijd opweegt tegen de performantiewinst die ge zou kunnen boeken.