Exception handling and monitoring in ASP.NET

Introduction

Exception handling is a crucial mechanism of application development. When exceptions occur frequently, things like increased CPU time consumption, memory leakage, and application slowness have a higher chance of happening. In case of uncaught exceptions, the application's run time can terminate. If an application can handle various exception types, it will be more robust and less prone to crashing. 

Since handling exceptions is vital for application development, tracking and monitoring them is significant for application performance optimization. Exceptions should be tracked because they're a treasure trove of information. In today's complex application environments, exceptions act as beacons for navigating the root cause of many potential problems. 

Read on to learn about handling exceptions in ASP.NET and various ways of using Site24x7's APM Insight .NET agent to track them.

What is an exception?

An exception is an execution fault or a conditional error that occurs during a program's execution. In general, when an exception is thrown, it's generated from where the problem occurred; exceptions are created as objects in .NET Framework and are inherited from the System.Exception base class. The exception is passed up the stack until the application handles it or the program terminates.

In general, exceptions can be handled by a try-catch-finally block in the code to prevent it from crashing.

Try-catch-finally blocks

Catch and finally are commonly used together in the code to obtain and use the resources in a try block, deal with exceptional circumstances in a catch block, and release the resources in the finally block. A try-catch statement contains a try block followed by a catch clause, which should catch an exception based on its type.

An application should use multiple catch blocks to handle different types of exceptions. Categorizing different exception types provides some visibility into a problem's exact type.

How Site24x7  instruments try-catch-finally blocks

APM Insight .Net agent tracks exceptions captured via logging providers (such as log4net, NLog, Serilog, and Enterprise Library) and shows exceptions thrown from their respective transactions. 

Figure 1 shows code with multiple catch blocks, each with different exception types, that will be captured by various logging providers.In cases where exceptions aren't captured via logging providers, they can be tracked using the .NET agent API by adding the following line of code to the desired catch blocks: DotNetAgent.Api.CustomTracker.TraceError(exception);

Figure 1. Example code with catch blocks for various exception types.

ASP.NET exception handling hierarchy in Site24x7

In an ASP.NET web application, exceptions are handled based on the following hierarchy:

• Application level
• Page level
• Code level
  • Error handling in web form applications
  • Error handling in MVC applications

Application-level error handling

Default errors at the application level can be handled either by modifying the application's configuration or by adding an Application_Error handler in the application's Global.asax file. All unhandled exceptions will be redirected to this event globally, so an error page can be implemented as part of this redirection event.

Figure 2. An exception, HttpUnHandledException, is captured and displayed.

Site24x7's APM Insight feature captures application-level exceptions by adding the API code to the Application_Error event. Figure 2 shows a HttpUnHandledException being captured and is shown under the trace details of the transaction "ticketweb/movie/checkavailability."

Page-level error handling

Exceptions at the page level are handled by sending users to an error page that displays a preconfigured error message. All control instances that are normally rendered on the page will be hidden, showing only the error.

Figure 3. When an exception isn't handled by the try or catch blocks, then an error page is shown with a pre-configured message. 

Specific page-level exceptions can be tracked using the agent API. An exception's complete stack trace is shown under the respective transaction trace details. This helps in tracking from where a particular exception is thrown.

Code-level error handling

In web form applications:

When an exception is thrown in web form applications, the common language runtime (CLR) looks for the corresponding catch block to handle that exception. If the method that is being executed doesn't contain the catch block, then the CLR goes up through the call stack looking for the method that called the current method.

Figure 4. A method for handling exceptions at the code level.

Code-level exceptions are handled via loggers or the .NET agent API. Then APM Insight captures those exceptions, along with the exception's severity, message, type, and stack trace.

In MVC applications:

In MVC applications, exceptions are handled at the controller or action level. The HandleError attribute helps in tracking exceptions at the code level; Figure 5 shows an example of this. 

Figure 5. The highlighted exceptions are handled by the HandleError attribute. Exceptions will be redirected to the given error view page and will show their respective transactions and stack traces. The HandleError attribute can be implemented at the controller or action level, as illustrated.

APM Insight tracks these exceptions automatically, without needing any additional code snippets. These exceptions will be shown under the Exceptions tab, along with their frequency.

Using custom loggers to track exceptions

Exceptions can also be handled via custom logging methods created by a user. Exceptions captured by custom logging methods can be logged in a file, database, or event log. Such exceptions are tracked via .NET Agent API and displayed under respective time frames.

Figure 6. The highlighted code shows an example custom logging method.

Figure 6 shows an example method, LogException, that would be used to log exceptions, and the exception data would be stored with its message, type, and stacktrace. 

By using Site24x7's APM Insight, these exceptions can be tracked by adding a line of code inside the custom logging methods mentioned above. In Figure 6, SQL exceptions tracked via the custom logger will be shown above the respective transactions that are thrown during this SQL exception. 

In general, APM Insight monitors all exceptions that occur in an application. These exceptions are tracked and presented with a view that is split up based on their respective transactions. Also, the timeline graph provides an overview of how often an exception is thrown, based on its severity level.

Figure 7. Site24x7's presentation of transactions grouped by exception type (on the left) and a timeline breakdown of exception count (on the right).

So what are you waiting for? Start tracking your exceptions and optimize your application performance with Site24x7!