[C#] resultcode & exception handling

[DrDelete]

Ik heb een rekenlibrary die veelal met returncodes werkt. In verschillende public methods zijn deze terug te vinden. Ze hebben allemaal een universeel gedrag. Indien deze > 0 teruggeven dan betekent dit een foutcode, indien < = 0 dan succes, indien < 0 dan is dit tevens een info code.

Deze library is niet meer te wijzigen en moet als black box worden beschouwd.

Het probleem: resultcodes worden in het algemeen afgeraden (zie exceptions onderdeel van Framework Design Guidelines van Krzysztof Cwalina, Brad Abrams). Men adviseert om gebruik te maken van specifieke exceptions.

Ik wil nu deze library wrappen zodat wordt voldaan aan de exception eis. Ik kan namelijk elke return code naar een private method lussen en deze method een exception laten raisen indien de returnwaarde > 0 is. Deze exception is dan een ArithmeticException.

Is dit de way-of-working ?

[prototype]

Indien het blackbox is en dus geen mogelijkheid meer is om de code te wijzigen, en je wil toch gebruik maken van de functionaliteit van de code dan is wrappen lijkt me de oplossing zoals je die hier ook voorstelt; i.e. de wrapper delegeert naar de blackbox en interpreteert de resultaten ervan en gooit indien nodig een exceptie.

[Swinnio]

Misschien heb je hier wat aan....

[whoami]

Vergeet wel niet dat het gooien van excepties duur is.
Het werken met resultcodes wordt idd over het algemeen afgeraden, maar in sommige gevallen is dat misschien wel de beste oplossing.

Ik vraag me trouwens af of het wel waard is om tijd en moeite te steken om daar een wrapper rond te maken, gewoon omdat je dan aan een of andere theorie voldoet.

[Hydra]

Mee eens. Vooral als die exceptions vaak optreden (hoewel het dan geen exceptions maar expections zijn ) is het het misschien niet waard die tijd er in te steken, helemaal als het een flinke performance penalty oplevert.

Als je dit toch wil doen, zoou ik het in iets dergelijks vatten:
Origineel:

code:

public int Calculate(string formula) { ... }

Naar:

code:

public Result Calculate(string formula) { ... }

Waar Result een result enum (duh ) is, welke een enum bevat van info codes (inclusief 'okay'). Als je dan een exception gooit, zou ik voor een ArithmeticException met als member een enum met het type exception (neem aan dat er meerdere resultcodes boven de 0 zijn) maken. Voor elk type exception een aparte exception class te maken die inherit van ArithmeticException lijkt me overkill.

[whoami]

Een exceptie is zowiezo iets wat maar zou mogen optreden als het niet verwacht is. (Hence de naam 'exception'). Bv, de connectie met de DB of het netwerk valt weg.

[curry684]

Hydra schreef op dinsdag 08 november 2005 @ 12:16:
Voor elk type exception een aparte exception class te maken die inherit van ArithmeticException lijkt me overkill.

In principe leidt wiskunde maar tot een beperkt aantal Exceptions, als je goed let op wat fatale en niet-fatale errors zijn. sqrt(-1) zou een InvalidInputException moeten gooien, pow(684,684) een OverflowException en div(5.4, 0) een DivisionByZeroException. Maar dan ben je al redelijk snel klaar met je fatal errors hoor.

[DrDelete]

Hydra schreef op dinsdag 08 november 2005 @ 12:16:
Mee eens. Vooral als die exceptions vaak optreden (hoewel het dan geen exceptions maar expections zijn ) is het het misschien niet waard die tijd er in te steken, helemaal als het een flinke performance penalty oplevert.

Als je dit toch wil doen, zoou ik het in iets dergelijks vatten:
Origineel:

code:

public int Calculate(string formula) { ... }

Naar:

code:

public Result Calculate(string formula) { ... }

Waar Result een result enum (duh ) is, welke een enum bevat van info codes (inclusief 'okay'). Als je dan een exception gooit, zou ik voor een ArithmeticException met als member een enum met het type exception (neem aan dat er meerdere resultcodes boven de 0 zijn) maken. Voor elk type exception een aparte exception class te maken die inherit van ArithmeticException lijkt me overkill.

Ik heb de exceptions er uit gesloopt. Nu heb ik de volgende oplossing bedacht:

* Indien het om een int return value gaat dan wordt dit vertaald naar een eigen Result class die een enum heeft en een detailmessage.
* Indien het om een complex type gaat (een struct of class) dan maak ik een eigen class er omheen waar de Result als property extra wordt opgenomen.

Zodoende heb je geen performance penalty en biedt je flexibilteit aan de caller.