Custom Error Handling for Contoso Pizza Web Api Tutorial - Demo
This tutorial and demo project will show how to set up, configure, and code a simple custom error handler for the Contoso Pizza Web Api project.
Developers should plan for unhandled errors in code. The Contoso Pizza Web API project demonstrates how to do this. In the demo, an endpoint is created that always throws an unhandled exception. The project has a custom error controller that handles and logs the exceptions before returning a standard Problem model object to the user. The error controller is specified in the Program configuration to route to a custom error controller when not running in a development environment. The development environment is specified under the Debug launch profile settings, with the default value being Production unless otherwise specified.
To see the differences in the error display between development and production, first run the API in development mode. Test the endpoint that always triggers an unhandled exception. In the Swagger UI, you can see the response and exception details. The browser window has a separate and elegant developer view of the error results.
To run the API in production mode, remove the environment variable or manually set the value to Production. Since Swagger UI does not run in production mode, you will need to test the API endpoint manually with a URL. The final result for the user is a general error with an identifier. A user would create a trouble ticket with this information. The company could then complete detailed troubleshooting matching the error identifier to more detailed internal logging.
GitHub Project Repo
https://github.com/kathleenwest/Conto...
Project Series - Azure Virtual Machine Web App Demo (5 Episodes) See Link Below
• Swagger Documentation Tutorial
Script
Developers should plan for unhandled errors in code.
The project shows us how to do this. Let's learn how.
For the demo, we create an endpoint that always throws an unhandled exception.
In our Program configuration, we specify the exception handler to route to a custom error controller when not running in a development environment.
The development environment is specified under the Debug launch profile settings.
The default value is Production unless otherwise specified.
The project has a custom error controller.
This will handle and log the exceptions before returning a standard Problem model object to the user.
Let's see the differences in the error display between development and production by first running the api in development mode.
We test the endpoint that always triggers an unhandled exception.
In the Swagger UI, we can see the response and exception details.
The browser window has a separate and elegant developer view of the error results.
To run our api in production mode, we first remove the environment variable or manually set the value to Production.
Swagger UI does not run in production mode, so we will need to test our api endpoint manually with a URL.
The final result for the user is a general error with an identifier.
A user would create a trouble ticket with this information.
The company could then complete detailed troubleshooting matching the error identifier to more detailed internal logging.