Chat Support
Loupe - Log - Monitor - Resolve
Loupe / Developer's Guide / For .NET Framework / For ASP.NET MVC / Developer's Guide for ASP.NET - Exception Handling
In This Topic
    Developer's Guide for ASP.NET - Exception Handling
    In This Topic

    In any web site, runtime errors are going to happen eventually.  The Loupe Agent works within the capabilities of the .NET framework to attempt to provide the best user experience possible when there are problems.  For a general discussion on runtime errors in .NET, see Developer's Guide - Exception Handling - Unhandled Exceptions in .NET.

    Default Agent Behavior

    The Loupe Agent for ASP.NET will automatically log any unhandled exception that occurs while processing a web request.  Additionally, the Loupe Agent connects up to the AppDomain.UnhandledException events to log any unhandled exception that occurs before the web site can exit.  Normally this second mode would only apply to threads you create yourself or when the ASP.NET agent is not configured.

    Even those these events are handled, it doesn't affect the end-user experience so you should still implement a custom error page for your site (they will still get the unhandled exception web page as configured in your web.config)

    There is no need to add code to the Global.asax file to log the exception to Loupe as long as the Loupe Agent for ASP.NET WebForms or MVC is added to your web application

    How Unhandled Exceptions are Shown

    When an unhandled exception occurs, the log message is attributed to the class and method where the exception was thrown.  If debug symbols are available the exact source code line will also be recorded.  If the exception was the result of processing a web site request then the basic request information (such as URL requested) is available in the details tab.

    Exception Notification vs. Handling

    The AppDomain.UnhandledException event is not an exception handler but rather an event that notifies you that an exception has occurred.  Once the event handler returns, the .NET runtime will end the process, potentially displaying a crash dialog to the end user.  In ASP.NET this would only happen due to exceptions on threads you create directly or in the event of an extraordinary failure of the ASP.NET framework.

    If you are directly working with thread pool threads or creating your own threads, always create a top-level try/catch block wrapping the Main entry point for the thread.  If you don't, any exception that is thrown out of the subroutine will cause the application domain to fail, which may take your web site offline momentarily.

    See Also