{"id":1792,"date":"2014-04-10T00:00:00","date_gmt":"2014-04-10T00:00:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/handling-errors-effectively-in-asp-net-mvc\/"},"modified":"2021-05-17T18:34:53","modified_gmt":"2021-05-17T18:34:53","slug":"handling-errors-effectively-in-asp-net-mvc","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/development\/dotnet-development\/handling-errors-effectively-in-asp-net-mvc\/","title":{"rendered":"Handling Errors Effectively in ASP.NET MVC"},"content":{"rendered":"
\n

Years ago,  ASP.NET’s error handling was one of the major things that made me wonder if ASP.NET MVC could give me something that ASP.NET Web Forms couldn’t. Web Forms is based on pages; so if something goes wrong, all that you can do is to redirect the user to another page and explain what the error was or just be generically sorry. ASP.NET Web Forms allow you to map an error page for each possible HTTP status code. You control the mapping through the <customErrors> <\/b> section of the web.config<\/b> file.<\/p>\n

Because of the  different architecture of the view in ASP.NET MVC,  it  is possible to save the redirect command and then programmatically switch to an error view in the context of the same request. You have this in addition to the regular page-based error handling mechanism. I wouldn’t use HTTP code redirects in ASP.NET MVC; but only because more flexible solutions are possible.<\/p>\n

Generally speaking, error handling in ASP.NET MVC is mainly necessary to handle program and route exceptions. Program exceptions refer to catching errors in controllers and in any code you may have in Razor views. Route exceptions refer to missing links and invalid URLs. <\/p>\n

Program Exceptions<\/h1>\n

Any stack trace you can have out of an ASP.NET MVC application originates from a method call in a controller class. The controller class, therefore, is where any exceptions in your ASP.NET MVC code can be trapped. You can do that in a number of equivalent ways. For example, you can have a try\/catch block surrounding the entire method body. It works, but it’s ugly to see too. A better option is probably to override the OnException <\/b>method from the base Controller class. Yet another option is using the HandleError <\/b>attribute at the controller class level. Better yet, the HandleError <\/b>attribute-which is ultimately an action filter-can be set globally on just every controllers and actions you can have.<\/p>\n

At the end of the day, an effective strategy for error handling is based on the following pillars:<\/p>\n