Explain CORE CLR - Exception Handling

This content delves into exception handling in CORE CLR (.NET Common Language Runtime), focusing on how the runtime manages errors in managed code. It covers the try-catch mechanism, error propagation, and best practices for robust .NET development.

In My last two blogs, we all went through two major functionalities of .NET CLR Garbage Collection & Code execution. In this blog, let us dig deeper into the exception handling by .NET CLR.

Before we move further, let’s understand what an exception is,

What is an exception?

Let’s go to my kitchen. I am going to prepare some chicken rice. I have planned my recipe and started preparing it. However, some unexpected situations can arise that can disrupt my cooking plan, such as,

1. I cut my fingers while chopping the onion
2. I am halfway through cooking, and I realize that I don’t have enough eggs to cook.
3. I accidentally left the food on the stove for too long; it got burned, and my wife came in (…. oops, it’s a crash ?)
4. Went out of cooking gas.

All these unexpected events which disrupt the normal plan are called exceptions. Whatever the case, if you handle the situation some things you can recover from, some you can’t ??. Same in the programming world.

Mainly the exceptions are raised in 2 ways,

1. CPU Raises an exception (access violations): This happens when the rules set by the CPU have been broken by the application during execution.
2. The application will ask the windows to raise an exception: The application can use the win32 functions and raise exceptions.

Now let’s see how these exceptions are handled with the help of a CLR. The CLR will utilize the help of Structured Exception Handling (SEH) which is a Windows-specific low-level exception handling mechanism that operates at the OS level to handle the CPU-level unmanaged exceptions. All the managed exceptions are handled by CLR itself.

Managed Exception & CLR

Let’s take the example of Cooking Chicken rice to explain this.

In the above example, suppose when an exception occurs while cutting the onions then the CLR propagates the exception on the call stack looking for a handler (in C# a catch block). It will look for a handler in Cut Onions. Suppose it has a handler. Say you will put a band-aid and proceed, then the CLR hands over the control to that block, and so Prepare vegetable operation will proceed with a band-aid on our finger. If we don’t have a handler there, then CLR will look up to prepare a vegetable method for any handler and then Cook Chicken and then prepare chicken rice; if it is not able to find any, the program will terminate, and there will not be any chicken rice for dinner. During this search for the handler, it unwinds the call stack, meaning it will exit one by one method until it reaches the end. We can handle the exception partially and rethrow it. Say suppose while preparing chicken, it got burned, So I will call my guest and tell me to please come home after dinner ?? and then will propagate to the top and terminate the preparation of chicken rice.

Alright, that’s the basics of Managed exception, now let’s see something beyond the control of CLR - unmanaged exceptions.

Unmanaged Exceptions & CLR

Unmanaged exceptions are exceptions that happen beyond the boundaries of CLR. But still, CLR will be able to handle those with the help of SEH. CLR will be able to convert the exceptions that occurred in unmanaged code to a managed exception with the help of SHE. The CLR Hooks into the SEH mechanism and on any exception, the CLR will receive it and stop further propagation in the SEH side. After receiving the exception from SEH, CLR will convert it to a managed exception type and propagate it to the call stack looking for a handler. CLR uses a mechanism called COMPlusFrameHandler to convert the exception from SEH to a .net exception.