Vyvolání výjimek
Poznámka:
Tento obsah je znovu vytištěn oprávněním Pearson Education, Inc. z Framework Design Guidelines: Conventions, Idioms a Patterns for Reusable .NET Libraries, 2. vydání. Tato edice byla publikována v roce 2008 a kniha byla od té doby plně upravena ve třetím vydání. Některé informace na této stránce můžou být zastaralé.
Pokyny pro vyvolání výjimek popsané v této části vyžadují dobrou definici významu selhání spuštění. K selhání provádění dochází vždy, když člen nemůže udělat to, co bylo navrženo k provedení (co název členu napovídá). Pokud například OpenFile metoda nemůže vrátit otevřený popisovač souboru volajícímu, považuje se za selhání spuštění.
Většina vývojářů se seznámila s používáním výjimek pro chyby použití, jako je dělení nulou nebo nulovými odkazy. V architektuře se výjimky používají pro všechny chybové podmínky, včetně chyb spuštění.
❌ NEvrací kódy chyb.
Výjimky jsou primárním prostředkem hlášení chyb v architekturách.
✔️ Selhání spuštění sestavy DO vyvoláním výjimek
✔️ Zvažte ukončení procesu voláním System.Environment.FailFast (funkce .NET Framework 2.0) místo vyvolání výjimky, pokud váš kód narazí na situaci, kdy je nebezpečné pro další spuštění.
❌ NEPOUŽÍVEJTE výjimky pro normální tok řízení, pokud je to možné.
S výjimkou selhání systému a operací s potenciálními podmínkami časování by návrháři architektury měli navrhnout rozhraní API, aby uživatelé mohli napsat kód, který nevyvolá výjimky. Můžete například poskytnout způsob, jak před voláním člena zkontrolovat předběžné podmínky, aby uživatelé mohli napsat kód, který nevyvolá výjimky.
Člen používaný ke kontrole předpokladů jiného člena se často označuje jako tester a člen, který skutečně dělá práci, se nazývá doer.
Existují případy, kdy model Tester-Doer může mít nepřijatelnou režii na výkon. V takových případech by se měl zvážit takzvaný model Try-Parse (další informace najdete v tématu Výjimky a výkon ).
✔️ ZVAŽTE dopad na výkon při vyvolání výjimek. Míra vyvolání vyšší než 100 za sekundu pravděpodobně výrazně ovlivní výkon většiny aplikací.
✔️ Zdokumentujte všechny výjimky vyvolané veřejně volatelnými členy z důvodu porušení smlouvy člena (místo selhání systému) a považovat je za součást vaší smlouvy.
Výjimky, které jsou součástí smlouvy, by se neměly měnit z jedné verze na další (tj. typ výjimky by se neměl měnit a nové výjimky by se neměly přidávat).
❌ Nemáte veřejné členy, které můžou vyvolat nebo ne na základě některé možnosti.
❌ NEMAJÍ veřejné členy, které vracejí výjimky jako návratovou out hodnotu nebo parametr.
Vrácení výjimek z veřejných rozhraní API místo jejich vyvolání porazí řadu výhod zasílání zpráv o chybách založených na výjimkách.
✔️ ZVAŽTE použití metod tvůrce výjimek.
Je běžné vyvolat stejnou výjimku z různých míst. Pokud se chcete vyhnout bloudí kódu, použijte pomocné metody, které vytvářejí výjimky a inicializují jejich vlastnosti.
Členové, kteří můžou vyvolat výjimky, se také neskládají do inliningu. Přesunutí příkazu throw uvnitř tvůrce může umožnit vložení člena.
❌ NEVYVOLÁVEJTE výjimky z bloků filtru výjimek.
Když filtr výjimky vyvolá výjimku, je výjimka zachycena CLR a filtr vrátí false. Toto chování je nerozlišitelné od provádění filtru a vrací hodnotu false explicitně a proto je velmi obtížné ladit.
❌ Vyhněte se explicitní vyvolání výjimek z bloků finally. Implicitně vyvolané výjimky vyplývající z volání metod, které jsou vyvolány, jsou přijatelné.
© Části 2005, 2009 Microsoft Corporation. Všechna práva vyhrazena.
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, published Oct 22, 2008 by Addison-Wesley Professional v rámci Microsoft Windows Development Series.