Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Opmerking
Deze inhoud wordt opnieuw afgedrukt met toestemming van Pearson Education, Inc. uit Framework Design Guidelines: Conventies, idioom en patronen voor herbruikbare .NET-bibliotheken, 2e editie. Die editie werd in 2008 gepubliceerd en het boek is sindsdien volledig herzien in de derde editie. Sommige informatie op deze pagina is mogelijk verouderd.
Richtlijnen voor het genereren van uitzonderingen die in deze sectie worden beschreven, vereisen een goede definitie van de betekenis van de uitvoeringsfout. De uitvoeringsfout treedt op wanneer een lid niet kan doen wat het is ontworpen om te doen (wat de lidnaam impliceert). Als de OpenFile methode bijvoorbeeld geen geopende bestandsgreep kan retourneren aan de aanroeper, wordt deze beschouwd als een uitvoeringsfout.
De meeste ontwikkelaars zijn op hun gemak geworden met het gebruik van uitzonderingen voor gebruiksfouten, zoals delen door nul of nul-referenties. In het framework worden uitzonderingen gebruikt voor alle foutvoorwaarden, inclusief uitvoeringsfouten.
❌ STUUR GEEN foutcodes terug.
Uitzonderingen zijn de primaire methode voor het rapporteren van fouten in frameworks.
✔️ DO rapporteert uitvoeringsfouten door uitzonderingen te genereren.
✔️ OVERWEEG het proces te beëindigen door de functie (.NET Framework 2.0) aan te roepen System.Environment.FailFast in plaats van een uitzondering te genereren als uw code een situatie ondervindt waarin deze onveilig is voor verdere uitvoering.
❌ GEBRUIK, indien mogelijk, geen uitzonderingen voor de normale controlestroom.
Met uitzondering van systeemfouten en bewerkingen met potentiële racevoorwaarden moeten frameworkontwerpers API's ontwerpen, zodat gebruikers code kunnen schrijven die geen uitzonderingen genereert. U kunt bijvoorbeeld een manier opgeven om voorwaarden te controleren voordat u een lid aanroept, zodat gebruikers code kunnen schrijven die geen uitzonderingen genereert.
Het lid dat wordt gebruikt om de voorwaarden van een ander lid te controleren, wordt vaak een tester genoemd en het lid dat het werk daadwerkelijk doet, wordt een doer genoemd.
Er zijn gevallen waarin het Tester-Doer-patroon een onaanvaardbare prestatieoverhead kan hebben. In dergelijke gevallen moet het zogenaamde Try-Parse-patroon worden overwogen (zie Uitzonderingen en prestaties voor meer informatie).
✔️ HOUD REKENING MET de gevolgen voor de prestaties van het genereren van uitzonderingen. Gooisnelheden boven 100 per seconde hebben waarschijnlijk een merkbare invloed op de prestaties van de meeste toepassingen.
✔️ DO documenteer alle uitzonderingen die worden gegenereerd door leden die publiekelijk kunnen worden aangeroepen vanwege een schending van het contract van het lid (in plaats van een systeemfout) en behandel ze als onderdeel van uw contract.
Uitzonderingen die deel uitmaken van het contract mogen niet worden gewijzigd van de ene versie naar de volgende (dat wil zeggen dat het uitzonderingstype niet mag worden gewijzigd en nieuwe uitzonderingen mogen niet worden toegevoegd).
❌ HEB GEEN openbare leden die uitzonderingen kunnen genereren afhankelijk van een bepaalde optie.
❌ Heb geen publieke leden die uitzonderingen retourneren als de retourwaarde of een out parameter.
Het retourneren van uitzonderingen van openbare API's in plaats van ze te genereren, verslaat veel van de voordelen van foutrapportage op basis van uitzonderingen.
✔️ OVERWEEG het gebruik van methoden voor het maken van uitzonderingen.
Het is gebruikelijk om dezelfde uitzondering op verschillende plaatsen op te werpen. Gebruik helpermethoden om code-bloat te voorkomen en uitzonderingen te maken en hun eigenschappen te initialiseren.
Leden die uitzonderingen genereren, worden ook niet geïnlined. Door de throw-instructie binnen de bouwer te verplaatsen, zou het lid mogelijk inline kunnen zijn.
❌ Werp geen uitzonderingen op uitzonderingsfilterblokken.
Wanneer een uitzonderingsfilter een uitzondering genereert, wordt de uitzondering gevangen door de CLR en retourneert het filter onwaar. Dit gedrag is niet te onderscheiden van het filter dat expliciet wordt uitgevoerd en expliciet onwaar retourneert en is daarom erg moeilijk te debuggen.
❌ VERMIJD expliciet uitzonderingen vanuit finally blokken te gooien. Impliciet gegenereerde uitzonderingen als gevolg van aanroepende methoden die worden gegenereerd, zijn acceptabel.
© Gedeelten 2005, 2009 Microsoft Corporation. Alle rechten voorbehouden.
Herdrukt door toestemming van Pearson Education, Inc. van Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition by Krzysztof Cwalina and Brad Abrams, gepubliceerd 22 oktober 2008 door Addison-Wesley Professional als onderdeel van de Microsoft Windows Development Series.