MVC 5: Error Pages - Advanced Logic
But our Kentico.Web.Mvc NuGet package also has some nice solutions to this problem. Eventually, we could re-use these design patterns for Kentico Cloud MVC 5 scenarios.
There are three artifacts in the package.
The custom CreateController method
At the beginning of a request, it takes the default stock ControllerFactory object, creates a new custom factory off that object and implements a modified CreateController method.
The biggest advantage of this pattern is that it allows handling of URLs to non-existing controllers.
This filter attribute is registered in the extension method mentioned above. You can decorate controllers or individual actions with it. Then the HttpNotFoundResult of failed requests would be handled with a proper 404 status code and a 'NotFound' view.
While the current implementation of this attribute deals with just the 'not found' situations, the implementation looks like a nice blend of both the HandleErrorAttribute and the IExceptionFilter.OnException method.
The custom InvokeAction method
There is also a custom InvokeAction created off the existing stock invoker object (wrapped around it). It is also done by the aforementioned extension method. The custom ActionInvoker implements the InvokeAction method which basically runs the controller action in a try/catch block.
Similarly to the custom CreateController and the HttpNotFoundErrorAttribute, it deals with just the 404 code. As with the CreateController implementation, it dynamically creates an ad-hoc 'HttpErrors' controller with a 'NotFound' action and processes it.
The above artifacts in the NuGet package have clear advantages and some disadvantages.
- Such functionality can be plugged into an MVC site through a NuGet package
- It can handle URLs to non-existent controllers
- It combines advantages of the stock HandleErrorAttribute and the OnException method
- Further configuration of the 'HttpErrors' controller would require some more coding than just writing the code of the error-handling controller directly
- Extending these artifacts would require more in-depth knowledge of the ASP.NET MVC 5 platform
Questions to discuss
The questions for this discussions could be guessed quite easily:
- Would you prefer creating a solution with a boilerplate error-handling code that you would modify in particular projects?
- Alternatively, would you like to participate in developing an open-source NuGet package with low-level robust logic?
- Do you have your custom logging logic in MVC 5 projects or do you use 3rd party toolsets? Which ones?
Feel free to discuss the topic here! We'd love to hear if this is what you'd use in your projects. Then, we could write an article and discuss how we can improve the Deliver .NET SDK, together with the community.