Undantagskastning
Kommentar
Det här innehållet skrivs om med behörighet från Pearson Education, Inc. från Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition. Den utgåvan publicerades 2008, och boken har sedan dess reviderats helt i den tredje utgåvan. En del av informationen på den här sidan kan vara inaktuell.
Riktlinjer för undantagsutkast som beskrivs i det här avsnittet kräver en bra definition av innebörden av körningsfel. Körningsfel inträffar när en medlem inte kan göra vad den har utformats för att göra (vad medlemsnamnet antyder). Om OpenFile metoden till exempel inte kan returnera ett öppnat filhandtag till anroparen anses det vara ett körningsfel.
De flesta utvecklare har blivit bekväma med att använda undantag för användningsfel som division med noll- eller null-referenser. 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 doer.
Det finns fall då Testare-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 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 undantagsverktygets metoder.
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. Om du flyttar throw-instruktionen i byggaren kan medlemmen vara inlindad.
❌ 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 uttryckligen utlösa undantag från slutligen block. Implicita undantag som genereras till följd av anropande metoder som genererar är acceptabla.
Portioner © 2005, 2009 Microsoft Corporation. Med ensamrätt.
Reprinted by permission of Pearson Education, Inc. from Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition by Krzysztof Cwalina and Brad Abrams, publicerad 22 okt 2008 av Addison-Wesley Professional som en del av Microsoft Windows Development Series.