Den här webbläsaren stöds inte längre.
Uppgradera till Microsoft Edge och dra nytta av de senaste funktionerna och säkerhetsuppdateringarna, samt teknisk support.
När en tjänst stöter på ett oväntat undantag eller fel finns det flera sätt att utforma en lösning för undantagshantering. Även om det inte finns någon lösning för "korrekt" eller "bästa praxis" för felhantering finns det flera giltiga sökvägar att överväga. Vi rekommenderar normalt att man implementerar en hybridlösning som kombinerar flera metoder från listan nedan, beroende på komplexiteten i WCF-implementeringen, typen och frekvensen för undantagen, undantagens hanterade eller ohanterade karaktär samt eventuella associerade spårnings-, loggnings- eller principkrav.
Dessa lösningar förklaras djupare i resten av det här avsnittet.
Programblocket för undantagshantering för Microsoft Enterprise-bibliotek hjälper till att implementera vanliga designmönster och skapa en konsekvent strategi för bearbetning av undantag som inträffar i alla arkitekturskikt i ett företagsprogram. Den är utformad för att stödja den typiska koden som finns i catch-instruktioner i programkomponenter. I stället för att upprepa den här koden (till exempel kod som loggar undantagsinformation) i identiska catch-block i ett program, tillåter undantagshantering av programblock utvecklare att kapsla in den här logiken som återanvändbara undantagshanterare.
Det här biblioteket innehåller en undantagshanterare för felkontrakt. Den här undantagshanteraren är utformad för användning vid WCF-tjänstgränser och genererar ett nytt felkontrakt från undantaget.
Programblock syftar till att införliva vanliga metodtips och tillhandahålla en gemensam metod för undantagshantering i hela programmet. Å andra sidan kan anpassade felhanterare och felkontrakt som utvecklats på egen hand också vara mycket användbara. Till exempel ger anpassade felhanterare ett utmärkt tillfälle att automatiskt höja upp alla undantag till FaultExceptions och även lägga till loggningsfunktioner i ditt program.
Mer information finns i Microsoft Enterprise-bibliotek.
Rätt åtgärd är att fånga förväntade undantag i varje åtgärd eller relevant utökningspunkt, avgöra om de kan återställas från och returnera rätt anpassade fel i ett FaultException<T>.
För att hantera oväntade undantag är det rekommenderade tillsättet att "koppla" en IErrorHandler. Felhanterare fångar bara undantag på WCF-körningsnivå ("tjänstmodell"-lagret), inte på kanallagret. Det enda sättet att koppla en IErrorHandler på kanalnivå är att skapa en anpassad kanal, vilket inte rekommenderas i de flesta scenarier.
Ett "oväntat undantag" är vanligtvis varken ett oåterkalleligt undantag eller ett bearbetningsundanstag. det är i stället ett oväntat användarfel. Ett oåterkalleligt undantag (till exempel ett undantag utan minne) – ett undantag som vanligtvis hanteras av undantagshanteraren för tjänstmodell automatiskt – kan vanligtvis inte hanteras korrekt, och den enda anledningen till att hantera ett sådant undantag alls kan vara att göra ytterligare loggning eller att returnera ett standardundantag till klienten. Ett bearbetningsundundanstag sker i bearbetningen av meddelandet , till exempel på serialiserings-, kodar- eller formateringsnivå, och kan vanligtvis inte hanteras på IErrorHandler, eftersom det i allmänhet är för tidigt eller för sent för felhanteraren att ingripa när dessa undantag inträffar. På samma sätt kan transportfel inte hanteras på en IErrorHandler.
Med en IErrorHandler kan du uttryckligen styra programmets beteende när ett undantag utlöses. Du kan:
Bestäm om ett fel ska skickas till klienten eller inte.
Ersätt ett undantag med ett fel.
Ersätt ett fel med ett annat fel.
Utför loggning eller spårning.
Utför andra anpassade aktiviteter.
Man kan installera en anpassad felhanterare genom att lägga till den i egenskapen ErrorHandlers för kanalutskickarna för din tjänst. Det är möjligt att ha fler än en felhanterare och de anropas i den ordning de läggs till i den här samlingen.
IErrorHandler.ProvideFault styr det felmeddelande som skickas till klienten. Den här metoden anropas oavsett vilken typ av undantag som genereras av en åtgärd i tjänsten. Om ingen åtgärd utförs här förutsätter WCF sitt standardbeteende och fortsätter som om det inte fanns några anpassade felhanterare på plats.
Ett område som du kanske kan använda den här metoden är när du vill skapa en central plats för att konvertera undantag till fel innan de skickas till klienten (se till att instansen inte tas bort och att kanalen inte flyttas till feltillståndet).
Metoden IErrorHandler.HandleError används vanligtvis för att implementera felrelaterade beteenden som felloggning, systemmeddelanden, avstängning av programmet osv. IErrorHandler.HandleError kan anropas på flera platser i tjänsten, och beroende på var felet utlöses kan HandleError-metoden anropas av samma tråd som åtgärden. inga garantier ges i detta avseende.
Ofta kan konfigurationsfel, databas anslutningssträng undantag och andra liknande undantag inträffa inom ramen för ett WCF-program, men är i sig inte undantag som orsakas av tjänstmodellen eller själva webbtjänsten. Dessa undantag är "vanliga" undantag utanför webbtjänsten och bör hanteras precis som andra externa undantag i miljön ska hanteras.
Spårning är den enda "catch-all"-platsen där man potentiellt kan se alla undantag. Mer information om spårnings- och loggningsfel finns i Spårning och loggning.
Med attributen WebGet och WebInvoke kan du ange en URI-mall som mappar komponenter i begärandeadressen till åtgärdsparametrar. Till exempel mappar URI-mallen "weather/{state}/{city}" begärandeadressen till literaltoken, en parameter med namnet state och en parameter med namnet city. Dessa parametrar kan sedan bindas med namn till några av de formella parametrarna för åtgärden.
Mallparametrarna visas i form av strängar i URI:n medan de formella parametrarna för ett skrivet kontrakt kan vara av icke-strängtyper. Därför måste en konvertering ske innan åtgärden kan anropas. Det finns en tabell med konverteringsformat .
Men om konverteringen misslyckas finns det inget sätt att låta åtgärden veta att något har gått fel. Typkonverteringen visas i stället i form av ett sändningsfel.
Ett typkonverteringsfel kan inspekteras på samma sätt som med många andra typer av leveransfel genom att installera en felhanterare. Utökningspunkten IErrorHandler anropas för att hantera undantag på tjänstnivå. Därifrån kan svaret som ska skickas tillbaka till anroparen – samt utföra anpassade uppgifter och rapportering – väljas.
Utbildning
Modul
Implementera undantagshantering i C#-konsolprogram - Training
I den här modulen går vi igenom användningen av undantag och processen för undantagshantering i C#-konsolprogram. Praktiska aktiviteter ger erfarenhet av att implementera undantagshanteringsmönster för olika kodningsscenarier.