[C#] Exception of return value vraagstuk

[pjonk]

Ik heb me de laatste tijd veel literatuur gelezen over Exception handling. Onder andere ook dit topic:
[rml][ alg] Exceptions, wanneer te gebruiken?[/rml]

Een aantal voordelen van exceptions ten opzichte van return values zijn mij bekend:
- Return values zijn makkelijker te negeren en Exceptions niet waardoor je gedwongen wordt om fouten af te handelen.
- Na een exceptie wordt geen code meer uitgevoerd. Als een database connectie fout gaat zullen er daarna nooit meer queries in de Class worden uitgevoerd.
- De applicatie is eenvoudiger te herstellen na een exceptie omdat de exceptie op de plaats van de aanroeper afgehandeld kan worden.

Nadelen Exceptions
- Het vaak throwen van Exceptions kan ongunstig zijn voor de performance van je applicatie

Nu zit ik met het volgende vraagstuk:
Ik heb Class gemaakt die wordt gebruikt in een ASP.NET webapplicatie. Deze Class kan aan de hand van een ingevoerde postcode de dichtsbijzijnde winkels vinden. In deze Class werkte ik met return values om verschillende situaties af te kunnen vangen:

C#:

public enum SearchResult
{
    InvalidPostalCode = 2, // Postcode formaat klopt niet
    PostalCodeNonExistent = 3, // Postcode bestaat niet
    DatabaseError = 4 // Database fout opgetreden
}

Nu wil ik deze Class gaan herschrijven met Exceptions en lijkt het me logisch om een Exception te throwen bij een Database error.

Over de InvalidPostalCode en PostalCodeNonExistent zit ik in dubio
Ik zou voor InvalidPostalCode een PostalCodeFormatException throwen. Dit betekent dat de ingevoerde postcode geen geldig formaat heeft.
PostalCodeNonExistent wordt teruggegeven indien de gebruiker een postcode invoert die wel een geldig formaat heeft, maar die niet bestaat (bijv. indien het een postbus is). Hiervoor zou ik een PostalCodeNonExistent exception kunnen throwen.

Exceptions zijn voor uitzonderlijke situaties af te vangen, maar deze fouten kunnen regelmatig optreden wat dus de performance zou kunnen schaden. Aan de andere kant wil ik ook afdwingen dat de aanroeper deze fouten afhandelt en dit kun je alleen afdwingen met Exceptions.

Ik ben benieuwd hoe jullie tegen dit vraagstuk aankijken

[Blizard]

Heb het hele topic van "Exceptions, wanneer te gebruiken" niet volledig doorgelezen, maar ikzelf gebruik geen exception voor 'fouten' die eigenlijk programma-logica zijn ?
Wanneer een postcode niet gevonden werd/verkeerde formaat werd ingegeven is het voor mij geen exception, maar een gewoon programma-verloop. Wanneer er inderdaad iets fout ging bij het opzetten van een database-connectie kan je wel spreken van een exception.

Ik quote even uit het topic dat je zelf aangaf :

Gebruik exceptions echter nooit om normale program-flow te definieren.

[ Voor 20% gewijzigd door Blizard op 13-11-2005 13:55 ]

[pjonk]

Blizard schreef op zondag 13 november 2005 @ 13:53:
Gebruik exceptions echter nooit om normale program-flow te definieren.

Ja maar de normale flow is natuurlijk dat de gebruiker een valide postcode opgeeft (wat in 99% van de gevallen zou moeten kloppen) waarbij hij vervolgens de resultaten te zien krijgt. Het kan natuurlijk zijn dat er geen winkels in de buurt zijn gevonden, maar dan return ik een dataset met 0 records (dus geen Exception).
Een verkeerde postcode opgeven of een niet bestaande vind ik dus geen normale program-flow. Ik moet zeggen dat ik dus geneigd ben om hiervoor wel Exceptions te gaan gebruiken.

[whoami]

De naam zegt het zelf al: een exception (uitzondering).
Die moet dus enkel gegooid worden bij 'uitzonderingen', onverwachte resultaten / situaties. (Bv, je wilt een netwerkresource benaderen en het netwerk is niet bereikbaar, een deling door nul is ook een exceptie, etc...

check ook dit topic
[rml][ C#] resultcode & exception handling[/rml]

[ Voor 13% gewijzigd door whoami op 13-11-2005 14:14 ]

[H!GHGuY]

ik zou iets doen als:

C#:

class WinkelLocatie
{
  // implementatie
}

class WinkelZoeker // pseudo-class
{
   WinkelLocatie[] zoekWinkel(int postcode)
   {
       ArrayList list = new ArrayList()
       if (!(onbestaand(postcode) || onmogelijk(postcode)))
       {
           try {  //opvullen }
           catch (databaseexceptie e) { throw WinkelExceptie("databankfout",e) }
       }
       return (WinkelLocatie[])list.toArray(typeof(WinkelLocatie));
   }
}

class GUI
{
     void doeIets()
     {
        try
        {
           WinkelLocatie[] winkels = new WinkelZoeker().zoekWinkel("88040");
           if (winkels.count == 0)
            // melding dat postcode fout of onbestaand is
           else
             // toon op scherm
        }
        catch (WinkelExceptie)
        {
          // er is een fout opgetreden bij eht verwerken van uw aanvraag... blah blah
        }
     }
}

[pjonk]

whoami schreef op zondag 13 november 2005 @ 14:12:
De naam zegt het zelf al: een exception (uitzondering).
Die moet dus enkel gegooid worden bij 'uitzonderingen', onverwachte resultaten / situaties. (Bv, je wilt een netwerkresource benaderen en het netwerk is niet bereikbaar, een deling door nul is ook een exceptie, etc...

Toch zijn de meningen hierover verdeeld. Ik quote even wat uit een boek dat ik hier heb Applied .NET Framework programming

Another common misconception is that an exception identifies an error. The term error implied that the programmer did something wrong.

An exception is the violation of a programmatic interface implicit assumptions. The interface you define carries with it some implicit assumptions. An exception occurs when an assumption made by your programming interface is violated.

Voor het geval postcode. Ik verwacht 4 cijfers of 4 cijfers en 2 letters. Als deze regel overtreden wordt overtreedt ik de interface assumptions van de class en zou ik dus een Exception moeten throwen.

P.S: Ik neem niet alles heilig over wat er in dat boek staat maar wat daar staat makes sense

[H!GHGuY]

pjonk schreef op zondag 13 november 2005 @ 14:24:
[...]

Toch zijn de meningen hierover verdeeld. Ik quote even wat uit een boek dat ik hier heb Applied .NET Framework programming

[...]


[...]

Voor het geval postcode. Ik verwacht 4 cijfers of 4 cijfers en 2 letters. Als deze regel overtreden wordt overtreedt ik de interface assumptions van de class en zou ik dus een Exception moeten throwen.

P.S: Ik neem niet alles heilig over wat er in dat boek staat maar wat daar staat makes sense

dat is ook wat je in Java en C# op zich wel meer ziet.
NullReferenceException, ArgumentException, ...

[pjonk]

[b][message=24594873,noline]HIGHGuY schreef op zondag 13 november 2005 @
dat is ook wat je in Java en C# op zich wel meer ziet.
NullReferenceException, ArgumentException, ...

Het is inderaad common practice in het .NET framework. Daarbij heb ik ook nog een andere situatie:
Ik heb een Class waaraan ik een pad naar een SelectionFile geef. Deze class probeert deze SelectionFile met een specifiek format in te lezen en te parsen.
Indien de SelectionFile niet bestaat of het pad niet bereikbaar is het duidelijk dan throw ik een Exception. Het kan ook voorkomen dat het format van de file niet klopt. Dan zou ik het logisch vinden om in deze situatie een SelectionFileParseException te throwen.

[curry684]

Another common misconception is that an exception identifies an error. The term error implied that the programmer did something wrong.

Zuiver gezien klopt dit. Een useractie mag namelijk nooit tot een 'vieze exception' aan de buitenkant leiden omdat je daarmee de black-box beginselen van UI/engine scheiding overtreedt. De engine mag exceptions gooien indien de UI zijn contracts niet naleeft, waarbij de UI dus de verantwoordelijkheid krijgt om ervoor te zorgen dat de invoer van de user gevalideerd is volgens de eisen. Ergo als je een exception naar de user door laat komen heeft de programmeur zich niet aan die regel gehouden.

Vaak is de waarheid minder zwart/wit en kun je exceptions wel degelijk gebruiken voor userfouten. Een MathException("Input value {0} is not between 32 and 96") kun je theoretisch gewoon in een nette dialog tonen. Je zit dan wel met de nadelen dat je in je engine je exceptions 'user-friendly' moet houden of afvangen en doorgooien, en je haalt je problemen op de hals met localization van foutmeldingen.