Undantagskastning

Riktlinjer för undantagshantering som beskrivs i det här avsnittet kräver en bra definition av innebörden av utförandefel. Körningsfel inträffar när en medlem inte kan utföra den funktion den är avsedd för (som namnet på medlemmen antyder). Om OpenFile-metoden till exempel inte kan returnera ett öppnat filhandtag till den som anropar, betraktas det som ett körfel.

De flesta utvecklare har blivit bekväma med att använda undantag för användningsfel som division med noll eller nollreferenser. I ramverket används undantag för alla felvillkor, inklusive körningsfel.

❌ Returnera INTE felkoder.

Undantag är det primära sättet att rapportera fel i ramverk.

✔️ RAPPORTERA körningsfel genom att utlösa undantag.

✔️ ÖVERVÄG att avsluta processen genom att anropa System.Environment.FailFast (.NET Framework 2.0-funktionen) i stället för att utlösa ett undantag om koden påträffar en situation där den är osäker för ytterligare körning.

❌ Använd INTE undantag för det normala kontrollflödet, om möjligt.

Förutom systemfel och åtgärder med potentiella konkurrensförhållanden bör ramverksdesigners utforma API:er så att användare kan skriva kod som inte utlöser undantag. Du kan till exempel ange ett sätt att kontrollera förhandsvillkoren innan du anropar en medlem så att användarna kan skriva kod som inte utlöser undantag.

Den medlem som används för att kontrollera förhandsvillkor för en annan medlem kallas ofta för en testare, och den medlem som faktiskt utför arbetet kallas en utförare.

Det finns fall då Tester-Doer-mönstret kan ha oacceptabla prestandakostnader. I sådana fall bör det så kallade Try-Parse-mönstret beaktas (se Undantag och prestanda för mer information).

✔️ ÖVERVÄG prestandakonsekvenserna av att utlösa undantag. Utkastshastigheter över 100 per sekund kommer sannolikt att påverka prestandan för de flesta program märkbart.

✔️ Dokumentera alla undantag som utlöses av offentligt anropbara medlemmar på grund av ett brott mot medlemsavtalet (i stället för ett systemfel) och behandla dem som en del av ditt kontrakt.

Undantag som ingår i kontraktet bör inte ändras från en version till en annan (dvs. undantagstypen bör inte ändras och nya undantag bör inte läggas till).

❌ HA INTE offentliga medlemmar som antingen kan kasta eller inte baserat på något alternativ.

❌ HA INTE offentliga medlemmar som returnerar undantag som returvärde eller som en parameter out.

Om du returnerar undantag från offentliga API:er i stället för att kasta dem kan du besegra många av fördelarna med undantagsbaserad felrapportering.

✔️ ÖVERVÄG att använda metoder för byggande av undantag.

Det är vanligt att utlösa samma undantag från olika platser. Undvik kodsvält genom att använda hjälpmetoder som skapar undantag och initierar deras egenskaper.

Medlemmar som utlöser undantag dras inte heller in. Genom att flytta kastuttrycket inuti konstruktorn kan medlemmen eventuellt bli inlinad.

❌ Utlöser INTE undantag från undantagsfilterblock.

När ett undantagsfilter genererar ett undantag fångas undantaget av CLR och filtret returnerar false. Det här beteendet kan inte skiljas från filtret som kör och returnerar false explicit och är därför mycket svårt att felsöka.

❌ UNDVIK att kasta undantag uttryckligen från finally-block. Implicita undantag som kastas till följd av att man anropar metoder som kastar är acceptabla.

Portioner © 2005, 2009 Microsoft Corporation. Alla rättigheter reserverade.

Återtryckt med tillstånd från Pearson Education, Inc. från Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition av Krzysztof Cwalina och Brad Abrams, publicerades den 22 oktober 2008 av Addison-Wesley Professional som en del av Microsoft Windows Development Series.

Se även

• Riktlinjer för ramverksdesign
• Designriktlinjer för undantag