Zobrazení vlastní chybové stránky (C#)
Co uživatel uvidí, když v ASP.NET webové aplikaci dojde k chybě za běhu? Odpověď závisí na konfiguraci vlastních chyb> webu<. Ve výchozím nastavení se uživatelům zobrazuje nevzhledná žlutá obrazovka s oznámením, že došlo k chybě za běhu. V tomto kurzu se dozvíte, jak přizpůsobit tato nastavení tak, aby zobrazovala esteticky příjemnou vlastní chybovou stránku, která odpovídá vzhledu a chování vašeho webu.
Úvod
V dokonalém světě by nebyly žádné chyby za běhu. Programátoři by napsali kód s chybou a robustním ověřováním vstupu uživatele a externí prostředky, jako jsou databázové servery a e-mailové servery, nikdy nepřešly do režimu offline. Ve skutečnosti jsou chyby samozřejmě nevyhnutelné. Třídy v rozhraní .NET Framework signalizují chybu vyvoláním výjimky. Například volání Metody Open objektu SqlConnection naváže připojení k databázi určené připojovacím řetězcem. Pokud je však databáze mimo provoz nebo pokud jsou přihlašovací údaje v připojovacím řetězci neplatné, metoda Open vyvolá SqlException. Výjimky lze zpracovat pomocí try/catch/finally bloků. Pokud kód v rámci try bloku vyvolá výjimku, ovládací prvek se přenese do příslušného bloku catch, kde se vývojář může pokusit chybu obnovit. Pokud neexistuje žádný odpovídající blok catch nebo pokud kód, který výjimku vyvolal, není v bloku try, výjimka se při hledání bloků propojí do zásobníku try/catch/finally volání.
Pokud se výjimka zobrazí až do ASP.NET modulu runtime bez zpracování, HttpApplicationvyvolá se událost třídy Error a zobrazí se nakonfigurovaná chybová stránka. Ve výchozím nastavení ASP.NET zobrazí chybovou stránku, která se s láskou označuje jako žlutá obrazovka smrti (YSOD). Existují dvě verze YSOD: jedna zobrazuje podrobnosti o výjimce, trasování zásobníku a další informace užitečné pro vývojáře při ladění aplikace (viz obrázek 1); druhý jednoduše uvádí, že došlo k chybě za běhu (viz obrázek 2).
Podrobnosti o výjimce YSOD jsou docela užitečné pro vývojáře při ladění aplikace, ale zobrazení YSOD koncovým uživatelům je hmatné a neprofesionální. Místo toho by se koncoví uživatelé měli dostat na chybovou stránku, která zachovává vzhled a chování webu s uživatelsky přívětivější práží popisující situaci. Dobrou zprávou je, že vytvoření takové vlastní chybové stránky je poměrně snadné. Tento kurz začíná seznámením s ASP. Na různých chybových stránkách. Potom ukazuje, jak nakonfigurovat webovou aplikaci tak, aby uživatelům zobrazovala vlastní chybovou stránku v případě chyby.
Zkoumání tří typů chybových stránek
Když v aplikaci ASP.NET dojde k neošetřené výjimce, zobrazí se jeden ze tří typů chybových stránek:
- Stránka s chybou Podrobnosti o výjimce – Žlutá obrazovka smrti
- Stránka chyby za běhu – Žlutá obrazovka s chybou smrti nebo
- Vlastní chybová stránka
Vývojáři nejvíce znají chybovou stránku s podrobnostmi o výjimce YSOD. Ve výchozím nastavení se tato stránka zobrazuje uživatelům, kteří navštíví místně, a proto se jedná o stránku, která se zobrazí, když při testování webu ve vývojovém prostředí dojde k chybě. Jak název napovídá, podrobnosti o výjimce YSOD poskytuje podrobnosti o výjimce – typ, zprávu a trasování zásobníku. A co víc, pokud výjimku vyvolal kód ve třídě kódu na pozadí vaší ASP.NET stránky a pokud je aplikace nakonfigurovaná pro ladění, zobrazí se v části Podrobnosti o výjimce YSOD také tento řádek kódu (a několik řádků kódu nad ním a pod ním).
Obrázek 1 znázorňuje stránku Podrobnosti o výjimce YSOD. Poznamenejte si adresu URL v okně adresy prohlížeče: http://localhost:62275/Genre.aspx?ID=foo. Vzpomeňte si, že stránka Genre.aspx uvádí recenze knih v určitém žánru. Vyžaduje předání GenreId hodnoty (a uniqueidentifier) prostřednictvím řetězce dotazu; například příslušná adresa URL pro zobrazení recenzí fikce je Genre.aspx?ID=7683ab5d-4589-4f03-a139-1c26044d0146. Pokud se hodnota, která neníuniqueidentifier , předá prostřednictvím řetězce dotazu (například foo), vyvolá se výjimka.
Poznámka
Chcete-li tuto chybu reprodukovat v ukázkové webové aplikaci, která je k dispozici ke stažení, můžete buď navštívit Genre.aspx?ID=foo přímo, nebo kliknout na odkaz "Generate a Runtime Error" (Vygenerovat chybu za běhu) v Default.aspx.
Všimněte si informací o výjimce uvedených na obrázku 1. V horní části stránky se zobrazí zpráva o výjimce "Převod se nezdařil při převodu z řetězce znaků na uniqueidentifier". V seznamu je uveden také typ výjimky System.Data.SqlClient.SqlException, . K dispozici je také trasování zásobníku.
Obrázek 1: Podrobnosti o výjimce YSOD zahrnují informace o výjimce
(Kliknutím zobrazíte obrázek v plné velikosti.)
Dalším typem YSOD je chyba modulu runtime YSOD, která je znázorněna na obrázku 2. Chyba modulu runtime YSOD informuje návštěvníka, že došlo k chybě za běhu, ale neobsahuje žádné informace o výjimce, která byla vyvolán. (Poskytuje ale pokyny, jak umožnit zobrazení podrobností o chybách úpravou Web.config souboru, což je součástí toho, proč takový YSOD vypadá neprofesionálně.)
Ve výchozím nastavení se uživatelům, kteří ho navštíví vzdáleně (prostřednictvím http://www.yoursite.com), zobrazí chyba YSOD za běhu, o čemž svědčí adresa URL v adresním řádku prohlížeče na obrázku 2: http://httpruntime.web703.discountasp.net/Genre.aspx?ID=foo. Tyto dvě různé obrazovky YSOD existují, protože vývojáři mají zájem znát podrobnosti o chybách, ale takové informace by se neměly zobrazovat na živém webu, protože by mohly odhalit potenciální ohrožení zabezpečení nebo jiné citlivé informace každému, kdo navštíví váš web.
Poznámka
Pokud postupujete podle pokynů a jako hostitele webu používáte DiscountASP.NET, můžete si všimnout, že se při návštěvě živého webu nezobrazí chyba modulu runtime YSOD. Důvodem je to, že DiscountASP.NET mají servery nakonfigurované tak, aby ve výchozím nastavení zobrazovaly podrobnosti o výjimce YSOD. Dobrou zprávou je, že toto výchozí chování můžete přepsat přidáním oddílu <customErrors> do Web.config souboru. Oddíl "Konfigurace zobrazené chybové stránky" podrobně prozkoumá <customErrors> oddíl.
Obrázek 2: Chyba modulu runtime YSOD neobsahuje žádné podrobnosti o chybách
(Kliknutím zobrazíte obrázek v plné velikosti.)
Třetím typem chybové stránky je vlastní chybová stránka, což je webová stránka, kterou vytvoříte. Výhodou vlastní chybové stránky je, že máte úplnou kontrolu nad informacemi, které se uživateli zobrazují, spolu se vzhledem a chováním stránky. Vlastní chybová stránka může používat stejnou stránku předlohy a stejné styly jako ostatní stránky. Část "Použití vlastní chybové stránky" vás provede vytvořením vlastní chybové stránky a konfigurací, aby se zobrazila v případě neošetřené výjimky. Obrázek 3 nabízí přehled této vlastní chybové stránky. Jak vidíte, vzhled a chování chybové stránky je mnohem profesionálněji než kterákoliv ze žlutých obrazovek smrti zobrazených na obrázcích 1 a 2.
Obrázek 3: Vlastní chybová stránka nabízí více přizpůsobený vzhled a chování
(Kliknutím zobrazíte obrázek v plné velikosti.)
Prohlédněte si panel Adresa v prohlížeči na obrázku 3. Všimněte si, že panel Adresa zobrazuje adresu URL vlastní chybové stránky (/ErrorPages/Oops.aspx). Na obrázcích 1 a 2 jsou žluté obrazovky smrti zobrazeny na stejné stránce, ze které chyba pochází z (Genre.aspx). Vlastní chybové stránce se předá adresa URL stránky, na které došlo k chybě, prostřednictvím parametru aspxerrorpath řetězce dotazu.
Konfigurace zobrazené chybové stránky
Která ze tří možných chybových stránek se zobrazí, je založená na dvou proměnných:
- Informace o konfiguraci v
<customErrors>části a - Určuje, jestli uživatel navštěvuje lokalitu místně nebo vzdáleně.
Oddíl<customErrors> v Web.config souboru má dva atributy, které mají vliv na zobrazenou chybovou stránku: defaultRedirect a mode. Atribut defaultRedirect je volitelný. Pokud je zadaný, určuje adresu URL vlastní chybové stránky a označuje, že by se měla zobrazit vlastní chybová stránka místo chyby modulu runtime YSOD. Atribut mode je povinný a přijímá jednu ze tří hodnot: On, Offnebo RemoteOnly. Tyto hodnoty mají následující chování:
On– označuje, že se všem návštěvníkům zobrazí vlastní chybová stránka nebo chyba modulu runtime YSOD bez ohledu na to, jestli jsou místní nebo vzdálení.Off– Určuje, že se podrobnosti o výjimce YSOD zobrazí všem návštěvníkům bez ohledu na to, jestli jsou místní nebo vzdálení.RemoteOnly– označuje, že se vzdáleným návštěvníkům zobrazí vlastní chybová stránka nebo chyba modulu runtime YSOD, zatímco místním návštěvníkům se zobrazí podrobnosti o výjimce YSOD.
Pokud neurčíte jinak, ASP.NET funguje, jako byste nastavili atribut mode na RemoteOnly hodnotu a nezadali defaultRedirect jste hodnotu. Jinými slovy, výchozí chování je, že podrobnosti o výjimce YSOD se zobrazí místním návštěvníkům, zatímco chyba modulu runtime YSOD se zobrazí vzdáleným návštěvníkům. Toto výchozí chování můžete přepsat přidáním oddílu <customErrors> do seznamu webových aplikací. Web.config file.
Použití vlastní chybové stránky
Každá webová aplikace by měla mít vlastní chybovou stránku. Poskytuje profesionálněji vypadající alternativu k chybě YSOD za běhu, je snadné ji vytvořit a nakonfigurovat aplikaci tak, aby používala vlastní chybovou stránku, trvá jen chvíli. Prvním krokem je vytvoření vlastní chybové stránky. Přidal(a) jsem do aplikace Recenze knih novou složku s názvem ErrorPages a přidal(a) jsem do této nové ASP.NET stránky s názvem Oops.aspx. Nechte stránku používat stejnou stránku předlohy jako ostatní stránky na webu, aby automaticky dědila stejný vzhled a chování.
Obrázek 4: Vytvoření vlastní chybové stránky
Potom věnujte několik minut vytváření obsahu chybové stránky. Vytvořil(a) jsem poměrně jednoduchou vlastní chybovou stránku se zprávou, že došlo k neočekávané chybě, a odkazem zpět na domovskou stránku webu.
Obrázek 5: Návrh vlastní chybové stránky
(Kliknutím zobrazíte obrázek v plné velikosti.)
Po dokončení chybové stránky nakonfigurujte webovou aplikaci tak, aby místo chyby modulu runtime YSOD používala vlastní chybovou stránku. Toho se dosáhne zadáním adresy URL chybové stránky v atributu oddílu <customErrors>defaultRedirect . Do souboru vaší aplikace Web.config přidejte následující kód:
<configuration>
...
<system.web>
<customErrors mode="RemoteOnly"
defaultRedirect="~/ErrorPages/Oops.aspx" />
...
</system.web>
</configuration>
Výše uvedený kód nakonfiguruje aplikaci tak, aby uživatelům, kteří navštíví místně, zobrazovala podrobnosti o výjimce YSOD, zatímco pro uživatele, kteří navštíví vzdáleně, používala vlastní chybovou stránku Oops.aspx. Pokud to chcete vidět v akci, nasaďte svůj web do produkčního prostředí a pak navštivte stránku Genre.aspx na živém webu s neplatnou hodnotou řetězce dotazu. Měla by se zobrazit vlastní chybová stránka (viz obrázek 3).
Pokud chcete ověřit, že se vlastní chybová stránka zobrazuje jenom vzdáleným uživatelům, navštivte Genre.aspx stránku s neplatným řetězcem dotazu z vývojového prostředí. Přesto byste měli vidět podrobnosti o výjimce YSOD (podívejte se zpět na obrázek 1). Nastavení RemoteOnly zajistí, že uživatelé, kteří navštíví web v produkčním prostředí, uvidí vlastní chybovou stránku, zatímco vývojáři pracující místně budou dál zobrazovat podrobnosti o výjimce.
Upozorňování vývojářů a protokolování podrobností o chybách
Chyby, ke kterým dochází ve vývojovém prostředí, způsobil vývojář sedící u svého počítače. Informace o výjimce se jí zobrazují v podrobnostech o výjimce YSOD a ví, jaké kroky prováděla, když došlo k chybě. Pokud ale dojde k chybě v produkčním prostředí, vývojář nemá žádné informace o tom, že došlo k chybě, pokud koncový uživatel, který navštíví web, nevybere čas na nahlášení chyby. A i když uživatel přestane upozorňovat vývojový tým, že došlo k chybě, bez znalosti typu výjimky, zprávy a trasování zásobníku může být obtížné diagnostikovat příčinu chyby, natož ji opravit.
Z těchto důvodů je nanejvýš důležité, aby se všechny chyby v produkčním prostředí protokolovaly do nějakého trvalého úložiště (například databáze) a aby vývojáři na tuto chybu získali upozornění. Vlastní chybová stránka se může zdát jako vhodné místo pro toto protokolování a oznámení. Vlastní chybová stránka bohužel nemá přístup k podrobnostem o chybě, a proto ji nelze použít k protokolování těchto informací. Dobrou zprávou je, že existuje několik způsobů, jak zachytit podrobnosti o chybách a zaznamenat je, a další tři kurzy se podrobněji zabývají tímto tématem.
Použití různých vlastních chybových stránek pro různé stavy chyb HTTP
Pokud je výjimka vyvolán ASP.NET stránkou a není zpracována, výjimka přejde až do modulu runtime ASP.NET, který zobrazí nakonfigurovanou chybovou stránku. Pokud požadavek přijde do modulu ASP.NET, ale z nějakého důvodu ho nelze zpracovat –například požadovaný soubor nebyl nalezen nebo byla pro soubor zakázaná oprávnění ke čtení – modul ASP.NET vyvolá HttpException. Tato výjimka, jako jsou výjimky vyvolané ze stránek ASP.NET, se zobrazí až do modulu runtime, což způsobí zobrazení příslušné chybové stránky.
Pro webovou aplikaci v produkčním prostředí to znamená, že pokud uživatel požádá o stránku, která nebyla nalezena, zobrazí se mu vlastní chybová stránka. Obrázek 6 ukazuje takový příklad. Vzhledem k tomu, že požadavek je určený pro neexistující stránku (NoSuchPage.aspx), HttpException vyvolá se příkaz a zobrazí se vlastní chybová stránka (všimněte si odkazu NoSuchPage.aspx v parametru aspxerrorpath řetězce dotazu).
Obrázek 6: Modul ASP.NET Runtime zobrazí nakonfigurovanou chybovou stránku v reakci na neplatný požadavek (kliknutím zobrazíte obrázek v plné velikosti).
Ve výchozím nastavení všechny typy chyb způsobují zobrazení stejné vlastní chybové stránky. Můžete však zadat jinou vlastní chybovou stránku pro konkrétní stavový kód HTTP pomocí <error> podřízených prvků v oddílu <customErrors> . Pokud chcete například zobrazit jinou chybovou stránku v případě chyby stránka nebyla nalezena se stavovým kódem HTTP 404, aktualizujte <customErrors> část tak, aby obsahovala následující kód:
<customErrors mode="RemoteOnly" defaultRedirect="~/ErrorPages/Oops.aspx">
<error statusCode="404" redirect="~/ErrorPages/404.aspx" />
</customErrors>
Po této změně bude pokaždé, když uživatel navštíví vzdálený požadavek na ASP.NET prostředek, který neexistuje, přesměrován na 404.aspx vlastní chybovou stránku místo na Oops.aspx. Jak znázorňuje obrázek 7 , 404.aspx stránka může obsahovat konkrétnější zprávu než obecná vlastní chybová stránka.
Poznámka
Podívejte se na chybové stránky 404. Ještě jednou najdete pokyny k vytváření efektivních chybových stránek 404.
Obrázek 7: Vlastní chybová stránka 404 zobrazuje cílenější zprávu než Oops.aspx
(Kliknutím zobrazíte obrázek v plné velikosti.)
Protože víte, že 404.aspx stránka je přístupná pouze tehdy, když uživatel odešle požadavek na stránku, která nebyla nalezena, můžete tuto vlastní chybovou stránku vylepšit tak, aby zahrnovala funkce, které uživateli pomohou tento konkrétní typ chyby vyřešit. Můžete například vytvořit databázovou tabulku, která mapuje známé chybné adresy URL na správné adresy URL, a potom nechat vlastní chybovou 404.aspx stránku spustit dotaz na tuto tabulku a navrhnout stránky, ke kterým se uživatel může pokoušet dostat.
Poznámka
Vlastní chybová stránka se zobrazí pouze v případě, že je požadavek na prostředek, který zpracovává modul ASP.NET. Jak jsme probrali v kurzu Základní rozdíly mezi službou IIS a ASP.NET Vývojový server , webový server může určité požadavky zpracovávat sám. Ve výchozím nastavení webový server služby IIS zpracovává požadavky na statický obsah, jako jsou obrázky a soubory HTML, bez vyvolání modulu ASP.NET. Pokud uživatel požádá o neexistující soubor obrázku, vrátí se mu výchozí chybová zpráva služby IIS 404 místo ASP. Nakonfigurovaná chybová stránka pro síť NET.
Souhrn
Pokud dojde k neošetřené výjimce v aplikaci ASP.NET, uživateli se zobrazí jedna ze tří chybových stránek: Podrobnosti výjimky Žlutá obrazovka smrti; Běhová chyba Žlutá obrazovka smrti; nebo vlastní chybovou stránku. Zobrazená chybová stránka závisí na konfiguraci aplikace a na tom, <customErrors> jestli uživatel navštěvuje místně nebo vzdáleně. Výchozím chováním je zobrazení podrobností o výjimce YSOD místním návštěvníkům a chyby modulu runtime YSOD vzdáleným návštěvníkům.
Chyba YSOD za běhu sice skrývá potenciálně citlivé informace o chybách před uživatelem, který web navštíví, ale přerušuje vzhled a chování vašeho webu a způsobuje, že vaše aplikace vypadá chybově. Lepším přístupem je použít vlastní chybovou stránku, která zahrnuje vytvoření a návrh vlastní chybové stránky a zadání její adresy URL v atributu defaultRedirect oddílu<customErrors>. Dokonce můžete mít několik vlastních chybových stránek pro různé stavy chyb HTTP.
Vlastní chybová stránka je prvním krokem komplexní strategie zpracování chyb pro web v produkčním prostředí. Důležitými kroky jsou také upozornění vývojáře na chybu a protokolování podrobností o chybě. V dalších třech kurzech se seznámíte s technikami pro oznamování chyb a protokolování.
Všechno nejlepší na programování!
Další čtení
Další informace o tématech probíraných v tomto kurzu najdete v následujících zdrojích informací: