Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
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ávání výjimek popsané v této části vyžadují dobrou definici selhání při provádě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í při provádění.
Většina vývojářů si zvykla na používání výjimek pro chyby v použití, jako je dělení nulou nebo nulové odkazy. V architektuře se výjimky používají pro všechny chybové podmínky, včetně chyb spuštění.
❌ NEVracejte kódy chyb.
Výjimky jsou primárním prostředkem hlášení chyb v architekturách.
✔️ Je třeba hlásit selhání vykonání 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 vzorec Tester-Doer může mít nepřijatelné výkonnostní náklady. 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 dopady na výkon při vyvolávání výjimek. Frekvence vyvolávání vyšší než 100 za sekundu pravděpodobně znatelně ovlivní výkon většiny aplikací.
✔️ Zdokumentujte všechny výjimky vyvolané veřejně volatelnými členy kvůli porušení smlouvy (nikoli kvůli selhání systému) a považujte 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.
❌ Nemějte veřejné členy, které vracejí výjimky jako návratovou hodnotu nebo jako 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.
Také členové, kteří vyvolávají výjimky, nejsou vkládaní do procesů. Přesunutí příkazu throw do generátoru může umožnit, aby byl člen vložen přímo.
❌ 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 filtrování, které explicitně vrací hodnotu false, a proto je velmi obtížné jej ladit.
❌ Vyhněte se explicitnímu vyvolávání výjimek z bloků finally. Implicitně vyvolané výjimky, které vznikají jako důsledek volání metod vyhazujících výjimky, jsou přijatelné.
Části z © 2005, 2009 Microsoft Corporation. Všechna práva vyhrazena.
Přetištěno se svolením Pearson Education, Inc. z Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition od Krzysztofa Cwaliny a Brada Abramse, vydáno 22. října 2008 nakladatelstvím Addison-Wesley Professional jako součást série Microsoft Windows Development.