MSDN Magazine - September 2008 - (Page 20)

Figure 3 Thread Created by the CLR invocation of the fault clauses if they are present. You may refer to the ECMA 335 specification (see go.microsoft.com/fwlink/?LinkId=121873) for specific details on fault clauses and managed exception handling in general. Under typical scenarios, the finally/fault blocks will execute and perform required cleanup. Once all such blocks are executed, the CLR will resume execution in the catch block (or the handler block for a managed filter) that agreed to handle the exception. In the previous examples, I had defined Main as the entry point managed frame for the thread—in other words, it is the first managed frame the thread will execute. If a managed exception handler is not found in it, the CLR will proceed to trigger its unhandled exception process. How this unhandled exception processing is triggered depends on how the thread was created. Let’s delve into this topic a bit more. Threads that can run managed code can be classified into two types. There are threads that are created by the CLR, and for such threads, the CLR controls the base (the starting frame) of the thread. The stack shown in Figures 1 and 2 is an example of this scenario. Figure 3 shows the true stack of such a thread when it starts within the CLR. There are also threads that are created outside the CLR but enter it at some later point to execute managed code; for such threads, the CLR does not control the thread base. The diagram in Figure 4 exemplifies this case. Thread Base and Unhandled Managed Exceptions In the case of Figure 3, if the CLR can’t find a managed exception handler in Main, the exception will reach the native frame within the CLR where the thread started. In this frame, the CLR has established an exception filter that will apply the policy to swallow (which is semantically equivalent to blindly catching) exceptions, if applicable. If the policy indicates not to swallow the exception (which is the default in the Microsoft® .NET Framework 2.0 and later), the filter triggers the CLR’s unhandled exception processing. At this point, you will likely want to know what kind of threads belong to the case depicted in Figure 3 and what the exceptionswallowing policy is. The answer to the first question is easy: any managed threads you create using the System.Threading.Thread class belong to this category. Additionally, the Finalizer thread and CLR thread pool threads also belong here. The only exception is a managed thread that is created in the default domain. Though such a thread would check the exception-swallowing policy, it will follow the same pattern as the thread in Figure 4 from the perspective of triggering unhandled exception processing, assuming the exception is not swallowed. The answer to the second question requires knowing a bit of the history of exception handling. In the .NET Framework 1.0 and 1.1, unhandled exceptions on threads that were created within the CLR were swallowed at the thread base (in other words, the native function at which the thread started in the CLR). In retrospect, this behavior could have been just the opposite since the CLR has no clue about the reason the exception was raised in the first place. Thus, swallowing such an exception, which none of the managed frames on the stack wanted to handle, is a mistake since the extent of application or process state corruption cannot be determined. What if the exception was the kind that would indicate a corrupted process state such as Access Violation, for instance? Unless you are working with unsafe managed code, there is no sense in swallowing such an exception. Most importantly, swallowing exceptions hides from the developer what actually went wrong in the application. Thus, in the .NET Framework 2.0, this behavior was changed. Unhandled exceptions on threads created by the CLR are no longer swallowed. If the exception is not handled by any managed frame on the stack, the CLR will let it go unhandled to the OS after triggering the unhandled exception process. The unhandled exception, then, will result in an application crash, and the details of the crash will help the developer to understand what went wrong. However, since certain applications built for the CLR 1.0 and 1.1 relied on the original behavior of swallowing unhandled exceptions, and subsequently wouldn’t work as expected against CLR 2.0, a flag was introduced that could be set in the application configuration file’s runtime section, as you see here: Unhandled Managed Exceptions on CLR-Created Threads Figure 4 Thread Created outside the CLR 20 msdn magazine Once set, exceptions would be swallowed just like they were in the CLR 1.0 and 1.1. This constitutes the exception swallowing policy of the CLR. If this policy is not applied, the CLR will proceed to trigger unhandled exception processing. CLR Inside Out http://go.microsoft.com/fwlink/?LinkId=121873

Table of Contents Feed for the Digital Edition of MSDN Magazine - September 2008

MSDN Magazine - September 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Office Space Cutting Edge Hierarchy ID New Features for Microsoft SQL Server 2008 Prism Data Services Advanced WPF Test Run Security Briefs Foundations { End Bracket }

MSDN Magazine - September 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.