it-swarm-eu.dev

Jaké jsou definitivní pokyny pro vlastní zpracování chyb v ASP.NET MVC 3?

Proces zpracování vlastních chyb v ASP.NET MVC (v tomto případě 3) se zdá být neuvěřitelně opomíjen. Přečetl jsem si různé otázky a odpovědi zde, na webu, stránky nápovědy pro různé nástroje (jako Elmah), ale mám pocit, že jsem odešel v úplném kruhu a stále nemám nejlepší řešení. S vaší pomocí možná můžeme nastavit nový standardní přístup k řešení chyb. Chtěl bych, aby to bylo jednoduché, a ne nadmíru.

Zde jsou mé cíle:

Pro chyby/výjimky serveru:

  1. Zobrazit informace o ladění v dev
  2. Zobrazte ve výrobě přátelskou chybovou stránku
  3. Chyby protokolu a e-mailem je správci ve výrobě
  4. Vraťte 500 stavového kódu HTTP

404 nenalezených chyb:

  1. Zobrazit přátelskou chybovou stránku
  2. Chyby protokolu a e-mailem je správci ve výrobě
  3. Vraťte 404 stavový kód HTTP

Existuje způsob, jak těchto cílů dosáhnout pomocí ASP.NET MVC?

44
RyanW

Budu sdílet to, jak jsem to nakonec udělal, to byla součást původní otázky.

Za prvé, problémy, se kterými jsem se setkal:

  1. Když je customErrors zapnuta (tj. Ve výrobě), globální atribut HandleError spolkne výjimky a vykreslí vaše zobrazení chyb, ale pak se nemůžete přihlásit pomocí nástroje addon jako elmah, protože elmah to nikdy nevidí. Dalo by se to podle vašeho názoru přihlásit, ale je to pohled, který se zdá být špatný. Globální atribut HandleError se objeví nový v MVC 3 RTM Šablona projektu Visual Studio).

  2. customErrors s adresami URL pro koncové body MVC vrací 302 stavových kódů. Existuje vlastnost redirectmode, ale nemůžete se shodovat s adresami mvc v customErrors a použít režim ResponseRewrite. ( https://stackoverflow.com/questions/781861/customerrors-does-not-work-when-setting-redirectmode-responserewrite/3770265#3770265 )

  3. Úplné vyhýbání se customErrors a manipulace se vším, co je ve vaší aplikaci běžné, vede k velké složitosti, IMO. (Miloval jsem to: https://stackoverflow.com/questions/619895/how-can-i-properly-handle-404s-in-asp-net-mvc/2577095#2577095 , ale nebylo 't pro náš projekt)

Moje řešení

MVC jsem z rovnice úplně vyřadil. Odebral jsem globální filtr HandleErrorAttribute global.asax a zaměřil jsem se výhradně na konfiguraci customErrors, přesunul jsem jej, aby používal přesměrování WebForm a změnil se na přesměrování na ResponseRewrite, abychom se vyhnuli 302 kódům HTTP HTTP .

<customErrors mode="On" defaultRedirect="/Error.aspx" redirectMode="ResponseRewrite">
  <error statusCode="404" redirect="/NotFound.aspx" />
</customErrors>

Poté v NotFound.aspx page_load událost, nastavte Response.StatusCode na 404 a v souboru Error.aspx nastavte kód 500.

Výsledek:

Cíle pro oba byly dosaženy pomocí protokolů Elmah, přátelské chybové stránky a stavového kódu s jedním řádkem kódu na pozadí kódů. Neděláme to „MVC Way“ jako dřívější řešení, ale s tím jsem v pořádku, pokud jde o dva řádky kódu.

23
RyanW

Myslím, že MVC, ASP a váš oblíbený rámec pro protokolování/výjimky mohou vaše cíle zvládnout docela pěkně. ELMAH i Enterprise Library poskytují snadno použitelné zpracování a protokolování výjimek, takže si vyberte své oblíbené .. I Nebudu chodit do výhod a nevýhod každého z nich.

POZNÁMKA: nemůžete zobrazit přátelskou chybovou stránku a vrátit HTTP 404 nebo 500, jak navrhuje vaše otázka. Když vrátíte přátelskou chybovou stránku, bude kód HTTP vrácený do vašeho prohlížeče 302.Toto je přesměrování na přátelskou chybovou stránku.

Přátelské chybové stránky

Vypadá to, že svých cílů můžete dosáhnout dobrým nastavením web.config, které bylo součástí ASP.net již nějakou dobu. Zmiňujete zobrazování informací o ladění, když jsou v dev, a zobrazování přátelských stránek ve výrobě. K tomu můžete použít sekci vlastních chyb web.config (Set CustomErrors = "Off" pro zobrazení informací o ladění). Budu předpokládat, že jste obeznámeni s atributem CustomErrors, pokud jej nečtete:

http://msdn.Microsoft.com/en-us/library/h0hfz6fc.aspx

Pokud potřebujete větší podrobnost kontroly nad zobrazením chybových zobrazení, použijte atribut HandleError MVC. Tímto způsobem si můžete vybrat různé pohledy na chyby pro každou akci/řadič.

http://weblogs.asp.net/scottgu/archive/2008/07/14/asp-net-mvc-preview-4-release-part-1.aspx

Protokolování výjimek

Zní to, jako byste chtěli reagovat na všechny vaše výjimky stejným způsobem („Protokolovat chyby a poslat je e-mailem správci ve výrobě“). Pokud je to váš případ, nejjednodušší možností je přidat kód

Application_Error (odesílatel objektů, EventArgs e)

ve vašem global.asax. Zde můžete předat vámi vybraný rámec protokolování.

Pokud chcete mít větší kontrolu nad protokolováním/zpracováním výjimek, můžete podtřídu HandleErrorAttribute a přepsat

OnException(System.Web.Mvc.ExceptionContext filterContext)

toto je další místo, kde můžete předat vámi vybraný rámec protokolování.

https://stackoverflow.com/questions/183316/asp-net-mvc-handleerror

To vám dává větší kontrolu než výše uvedená technika Application_Error.

Obecně MVC vám dává velkou granularitu kontroly nad tím, jak řešit chyby. Pokud tuto kontrolu nepotřebujete, můžete se vrátit zpět k ASP.net způsobům, jak dělat věci, jako je definování chybových stránek ve vašem web.config.

5
nixon