Hej,

Jag vet att det har blivit lite diskuterat förut ang. felhantering men jag har ett projekt som kan kräva bra felhantering.

Det handlar om ett intranät för många anställda. Jag vill lagra alla fel som ev. dyker upp.
Validering sker via client-skript i PL samt validering i BLL för att inga fel skall uppstå. Om fel uppstår så återrapporteras detta till användaren. När valideringsfel uppstår så lagras även felen i databas för att vi skall kunna följa upp och förbättra för användaren.

Nu till frågan:
- Vad, vart och hur skall jag logga ev. fel samt ev. valideringsfel?
- Att bygga egna exceptions som man kastar vid ev. fel, kan det vara en ide? Då kan man i PL hantera felen och basera felmeddelanden till användaren på vilket exception som kommer upp? Finns det några artiklar kring detta, om det är en bra ide?

JAg skulle fördera att kasta egna exceptions.
Det finns visa fall som man på förhand kan identifera så varför inte skapa ett eget exception för dessa. Du kan dessutom skicka med orginal exceptionent i dessa.

Vanliga fel med databaser:
* Värde är störren äv vad databasen kan lagra
* Det finns redan en post med samma nyckel/index
* Brott mot referensintegriteten
osv...

Jag tycker inte att varje dataclass, typ customer, skall ha sin egna exeption. Undantag är om det är ett fel som bara kan uppstå just för den. Däremot kan du anpassa meddelandet till användaren specifikt för varje dataklass. Så att felmeddelandet är så talande som möjligt. Men detta kanske är bättre att göra i presentationslagret.

Lite av mina funderingar du kan spåna vidare på.

Exceptions är till för vad de heter, dvs undantag.

Att kasta exceptions i en webbapplikation är dyrt och äter upp throughput. Dessutom låter det mig bara validera en sak åt gången.

Jag föredrar att göra ngt liknande det följande istället:

public bool ValidateCustomerInformation(Customer enteredCustomerInformation, out List<string> validationErrors) {

   validationErrors = new List<validationErros>();
   bool isValid = true;

   if ( !InputService.IsValidEmail(enteredCustomerInformation.Email) ) {
       validationErrors.Add("Email not in a valid format");
       Trace.Warn("Validation", string.Format("{0} was sent as an email address");
       isValid = false;
   }
   
   if ( !InputService.IsValidZipCode(enteredCustomerInformation.ZipCode) ) {
       validationErrors.Add("Email not in a valid format");
       Trace.Warn("Validation", string.Format("{0} was sent as a ZipCode address");
       isValid = false;
   }
   
   return isValid;
}

Varför är undantag dyrt? Måste det vara det?

Det har med hur det exception objekten flödar utanför callstacken i contextet att göra.

De är dyra på flera plattformar där man använder liknande modeller, så jag antar att det är ngt konceptuellt.

Enligt följande tråd behöver inte undantag vara dyra, och kan bli billigare än att kolla returvärden från vartenda funktionsanrop.
http://www.velocityreviews.com/forums/t282710-how-are-exception-expensive.html

Jag kan inte argumentera för eller emot den tråden.

Men det jag vet är att problemet finns i Java, .NET, VC++, delvis i Delphi och även i VB6.

Jag skulle säga att det är mest en myt att vanliga exceptions har någon mätbar påverkan på prestanda i en vanlig applikation.
Exceptions är något som sker helt internt i koden utan utomstående beroenden. Jämfört med hur lång tid det tar att göra ett databas- eller filsystemanrop är exceptions helt försumbart.

Naturligtvis går det att konstruera exempel med någon loop som beräknar något utan externa beroenden som går snabbare utan exceptions men hur vanligt är det.

Den vanliga rekommendationen är väl att man inte skall göra prestandaoptimering på förhand. Det gäller väl även exceptions.

Absolut.
Databasanrop är dyrare. Men det innebär inte att man skall ignorera det. Det är ungefär som att säga "jag slutat konkatenera strängar när jag får ett problem" hur kul blir det då när du i slutet av projektet kanske måste gå tillbaka och ändra all stränghantering.

Jag gillar tankesättet om att undvika pre-optimization, men begreppet är introducerat vad gäller att skapa nya komplexitetsnivåer i dina lösningar för att optimera, inte för sunt förnuft och best-practices. Tex konkatenerar man inte strängar hursomhelst, eftersom det är lika enkelt att använda andra varianter som inte introducerar ngn komplexitetsnivå och är effektivare. Samma gäller exceptions, att ha returvärden istället för exceptions skapar inte ngn ytterliggare komplexitetsnivå för koden.

Visst är det så att ett databasanrop kostar mer, men jag gillar att låta databasanropet vara den enda flakshalsen. Dessutom är det så att i just web applikationer (och servertillämpningar i allmänhet) har det en enorm effekt på throughput. Jag leverera bla en workshop där man gör optimering och mätning av webapplikationers prestanda, och minskar man användningen av Exceptions är en av de åtgärder som ger en kraftigt mätbar skillnad i throughput.

I övrigt: "Exceptions är något som sker helt internt i koden utan utomstående beroenden."
Det här stämmer inte, Exceptions hanteras (i .NET fallet) utanför din applikation, allt du gör är att kasta det. Hanteringen av det sker i CLRn, dvs utanför din direkta applikation.

Uppskattar diskussionen men det känns som om det hela blivit off-topic.

Ta en titt högst upp på sidan, baserat på artiktektur hur skall jag åtgärda detta?

Som jag har fortsatt läst så:
- Kasta exceptions i t.ex BLL och låta det bubbla upp till PL. Väl i PL så:
1. Lagra felet om det är nödvändigt
2. Ge felmeddelanden baserat på vilket felmeddelanden det är.

Är detta tankesätt korrekt anser ni?