Join Jess Chadwick for an in-depth discussion in this video Adding Error Handling and Diagnostics, part of Up and Running with ASP.NET 5.
- Throughout this course, I've shown you several cases where the code that we've written has resulted in error during request processing. Sometimes, that error has resulted in an error message being displayed to the user. Other times, however, it's resulted in a blank page with no other information for the user to understand what happened or what they can do about it. In this video, I'll show you how to react to those errors in a much more user-friendly manner. Let's start out by adding a controller action to our application that always produces an error, so we can refresh our memory as to what the default error page looks like.
To do this, go to the home controller, and add the following controller action. That will allow us to cause an error whenever we like. Then, we can run the application, and navigate to /home/causeanerror to see the error in the browser. There, now we've got a good example of an error page to clean up. Because error pages, such as the ones we'd like to display in our application, are such a common problem, the ASP.NET team has actually provided us with some libraries to help give us a little more information about the problems we're having, so we don't have to write the code to do it ourselves.
It's another piece of middleware, much like the ASP.NET MVC framework we've been using, and, like the ASP.NET MVC framework, in order to start using it, we've got to register it with the ASP.NET middleware pipeline. Like all the other functionality we've added in this course, the first thing we need to do in order to use the error and diagnostics middleware libraries, are to add the package to our project. To do this, open up the project.json file, and add the package named Microsoft.AspNet.Diagnostics as a dependency.
Then, open up our Startup class, and jump down to the Configure method, and add the command app.UseErrorPage Be sure to run this command before any other middleware, such as the MVC middleware, is registered, so that it has the first say in how errors are handled. Then, save the file and switch back to the browser that's currently showing the old error page, and refresh this page to see the new error page middleware jumping in and showing us a much more nicely formatted error page than that default error page. The diagnostics library also gives us another cool piece of middleware.
To see it in action, simply add the line app.UseRuntimeInfoPage Then, switch over to your browser and navigate to /runtimeinfo to see the list of libraries our application is currently referencing, as well as their version numbers and location on disc. All this information is very useful in troubleshooting when assembly versioning issues arise. Now, all of this diagnostics information is great for us as developers when we're developing our application, but we don't want real users to see this stuff, do we? Well the diagnostics library actually gives us one more really helpful piece of middleware, and that is app.UseErrorHandler This middleware actually listens for any exceptions that may occur during the course of a request, and then logs the error and redirects the request to a friendly error page that is more helpful for a user of the site, who doesn't really care about the stack trace in which the error occurred.
In order to work, this middleware requires the path to the page that should be displayed when an error occurs. Since we don't yet have such a page in our site, we'll just tell the user error handler middleware to reroute requests to the /home/error URL, and then we'll quickly go ahead and create a new controller action at this URL to display this error page. The quickest way to do this is just copy the existing index action and rename it to Error. Likewise, we can just copy the existing index view and rename it to Error, and then open up that view, and replace all of its markup with a simple error message.
When I'm done, I'll switch back to the browser, and refresh the page to try it out. When I refresh the URL that we added before that produces an error, I see by the error page shown in the browser that my custom error page logic has executed properly. And there you have it, a basic custom error page.
- Understanding ASP.NET 5's new request processing pipeline
- Downloading client-side libraries using Grunt and Bower in Visual Studio
- Adding ASP.NET MVC 6 to your application
- Handling web requests with controllers
- Rendering dynamic views with Razor markup
- Using Entity Framework to write and read data to a database
- Using TagHelpers to create simple dynamic HTML forms
- Registering and authenticating users with Identity services
- Dynamically update portions on the server using partial rendering
- Using dynamic routing logic to customize URLs
- Exposing data with web APIs
- Leveraging custom configuration and logging
- Increasing application maintainability with dependency injection