Hej, Min fråga till dig är då om du verkligen vill visa hela felkedjan? Vissa fel kan innehålla information som en användare skulle kunna använda sig av för att hacka ett system. Mitt förslag är att du enbart visar att ett fel har uppstått, sedan loggar du felet (tex med Microsoft P&P Exception Manager Applicaiton block) till en eller flera datakällor, tex skickar ett mail till administratlren för siten eller skriver ner det i event loggen, database eller XML etc. Det har du rätt i. Hej, Per!Felhantering i flera lager
Jag söker en bra strategi för felhantering för ett system (asp.net - vb) som består av 5 lager. Det kan också vara fel från databasen.Kan jag, och i så fall hur, skriva en klass som hanterar mina fel. Eller ska jag kasta upp felen till web-sidan? Jag vill använda mig av "collection av fel". Dvs jag vill kunna visa alla fel på en gång för användaren.
Tacksam för hjälpSv: Felhantering i flera lager
Sv:Felhantering i flera lager
Hur du något tips på hur jag kan bygga upp min felhantering?
Jag har ett datalager, ett busniesslager, user interface components samt user interface. Som databashaterare använder jag sql server.
Jag vill kunna visa användaren att något gått fel samt kunna visa meddelande från sp där en kontroll kanske visat att användaren matat in ett värde som inte är ok (tex för stort värde gemfört med vad användaren har rätt till enligt användartabellen). Skapar jag en klass för varje feltyp eller hur gör jag?Sv: Felhantering i flera lager
Finns ju som vanligt inga rätt eller fel hur man ska göra. Skrev nyligen en (ändock rätt liten) applikation där jag bl a tog hand om felhantering vad gäller fältvalidering i UI Components. Andra regler evalueras i SP och felmeddelande "kastas" därifrån. Ytterligare regler valideras i Business Layer, där "objektpuristen" kanske säger att alla regler ska valideras.
I Business Layer tycker jag man t ex kan ta hand om SqlException, skapa ett nytt ApplicationException (användarvänligt) som "kastas" vidare uppåt i lagerarkitekturen, och sedan skriver (tekniskt) SqlException till t ex eventloggen. Själva logg-hanteringen bör man separera till en egen komponent, för att slippa göra om i varje Business-objekt. Man kan nyttja färdiga Application Block från MS P&P, som Fredrik nämner ovan. Dom har oxå många goda riktlinjer för hur man separerar dylika åtaganden (som t ex logging) ifrån övriga Business-komponenter.
Nämnas bör kanske oxå att kasta Exceptions "kors o tvärs" kostar en del resurser. Ibland har man givetvis inga andra val, och ibland prioriterar man struktur o enkelhet före prestanda.
I Business Layer tycker jag man kan "mappa" verksamhetsklass -> felklass, t ex Customer har en CustomerException (ärver av ApplicationException), eller "kasta" ApplicationException direkt, beroende påambitionsnivå.