Uitzondering die wordt gegenereerd
Notitie
Deze inhoud wordt opnieuw afgedrukt door toestemming van Pearson Education, Inc. van Framework Design Guidelines: Conventions, Idioms en Patterns for Reusable .NET Libraries, 2nd Edition. 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 vertrouwd geworden met het gebruik van uitzonderingen voor gebruiksfouten, zoals delen door nul- of null-verwijzingen. In het framework worden uitzonderingen gebruikt voor alle foutvoorwaarden, inclusief uitvoeringsfouten.
❌ RETOURNEER GEEN foutcodes.
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 zijn waarschijnlijk merkbaar van invloed op de prestaties van de meeste toepassingen.
✔️ DO documenteer alle uitzonderingen die worden veroorzaakt door openbaar aanroepbare leden vanwege een schending van het lidcontract (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).
❌ GEEN openbare leden hebben die wel of niet kunnen worden gegooid op basis van een bepaalde optie.
❌ GEEN openbare leden hebben 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 te gooien. Gebruik helpermethoden om code-bloat te voorkomen en uitzonderingen te maken en hun eigenschappen te initialiseren.
Leden die uitzonderingen genereren, worden ook niet inline weergegeven. Als u de instructie throw binnen de opbouwfunctie verplaatst, kan het lid inline 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 retourneert onwaar en is daarom erg moeilijk om fouten op te sporen.
❌ VERMIJD expliciet uitzonderingen van uiteindelijk blokken te genereren. Impliciet gegenereerde uitzonderingen als gevolg van aanroepende methoden die worden gegenereerd, zijn acceptabel.
© Delen 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, published oct 22, 2008 by Addison-Wesley Professional als onderdeel van de Microsoft Windows Development Series.