uppose you’ve obtained unmanaged resources in a class constructor during object construction and the created object was provided to a using statement. However, the resources were not released at the end of the using statement’s usage block. Instead, they were released during garbage collection, as you may expect. Sorting through the application’s IL code with the DbgCLR debugger, you find that an exception was thrown from the class constructor. So, not only was the object not fully constructed, the Dispose() method was not called when the unmanaged resources were expected to be released. Thus, they were not released and contributed to the resource consumption.

Resource consumption may impede your application’s performance metrics or may even prevent it from working at all.

Add try/catch blocks in the constructor to release unmanaged resources.

Finding the Solution
I created a small application to test the using statement’s behavior and to investigate different ways to release the unmanaged resources acquired by the failed constructor.

Here’s the code for the application:

static void Main(string[] args){	using(A a = new A())  // A : IDisposable  implements the dispose pattern{   //point1    . . .}   //point2. . . }

And here’s the stripped IL code:

.locals init ([0] class MyApplication.A a)IL_0000:  newobj     instance void MyApplication.A::.ctor()IL_0005:  stloc.0.try{IL_0006:  leave.s    IL_0012}  // end .tryfinally{IL_0008:  ldloc.0            IL_0009:  brfalse.s  IL_0011            IL_000b:  ldloc.0            IL_000c:  callvirt   instance void [mscorlib]System.IDisposable::Dispose()            IL_0011:  endfinally}  // end handler

The IL code shows that, according to the C# specification, if an exception is thrown between point1 and point2, Dispose() is called on the instance of A and necessary clean up is performed. This clean up includes the release of unmanaged resources.

When the exception was thrown from the A() constructor, the above finally block was not executed. This is why the code should be updated to release the allocated resources that can be leaked.

Initial Attempts
My first strategy was to write an explicit try/catch block around the using statement and, from there, call a.Dispose(). Of course, this garnered a CS0246 compile time error because “the type or namespace name ?a? could not be found.” Therefore, I decided to declare the a variable before the try block. The code compiled, but resulted in a NullReferenceException exception because “Object reference not set to an instance of an object.”

Checking if a is not null before calling a.Dispose() eliminates the runtime error, but also abolishes the call to a.Dispose() because a, in this case, will definitely be null. Any other exercises that involved moving trycatch blocks and instantiating type a did not help either. Thus, it became evident that the mix of an explicit trycatch block was not getting along with the implicit tryfinally block when both of them call a.Dispose().

An alternative solution to the problem was to add a try/catch block inside the A() constructor to guard places that may throw an exception. This guarding method releases previously acquired unmanaged resources in the constructor’s catch block after the point of failure. It was a solution. I released unmanaged resources inside the failed constructor, rethrew the exception, and used the trycatch explicit block around the using statement.

Wrapping Up
In order to release the unmanaged resources obtained during construction as soon as possible, consider employing:

• The using statement if an exception can be thrown during the usage part.
• Explicit try/catch blocks in the constructor if an exception can be thrown from the constructor.
• You may prefer to allocate resources outside of the constructors, allowing them to initialize only data members, thus constructing your memory models in two stages. In this case, the using statement will work as it was intended.

New Roadblocks
Adding try/catch blocks in the constructor and releasing unmanaged resources brings an additional issue into discussion: How do you return from the failed constructor? One possible way is to rethrow the exception. Another method is to throw another exception and then catch it in the calling code. You may not like over-engineering with the additional trycatch block around the using statement that is required in these cases. So another way is to use an A constructor with parameters instead of the parameterless constructor shown above. You may set the bool Result status flag in the o object, which is then passed to the A(UserRefType o) constructor in the using statement. In this case, you would add something like if (o.Result) after returning from the constructor. If you dislike using status flags, you might also consider dropping the using statement altogether and employing just a try/catch/finally block.

Take care to carefully construct the Dispose() method with the following considerations in mind:

• The method may need to know how the constructor or usage block was exited?at its end or after an exception was thrown somewhere in its body. It might be necessary to execute some actions?for instance ?undo??based on this knowledge.
• The method may throw its own exceptions before it processes a thrown exception. This behavior will mask the original exception and may change an expected execution order.
• The method may change the state of the object that could be passed to the A(UserRefType o) constructor. This new state may cause runtime errors or misbehavior when the o object is used later.

Additional Considerations
The following code presents an IL instruction that looks at the value on the stack:

	IL_0009:  brfalse.s  IL_0011

If it is 0, or a null reference, it will break. Generally, having this instruction prevents failure to call the Dispose() method when c is null, as in the following code:

C c = C();     //C does not derive from IDisposableusing(c as IDisposable)  {	. . . }

Because c must be of the System.IDisposable type or a type that can be implicitly converted to System.IDisposable, you need to use the as operator to allow the C# compiler to compile this code without errors.

This article doesn’t discuss why you would write code like this?it just highlights the IL implementation of the finally block. Of course, if C is derived from IDisposable() and the C() constructor failed, Dispose() will not be called here either.

Those who are familiar with native C++ and the RAII (Resource Acquisition Is Initialization) pattern will remember that the following block:

{	classX x;   //x is allocated on the stack	//point3	?..            //point4}

guarantees the call of the ~ClassX() destructor?even if an exception has been thrown in this block between point3 and point4. If the constructor throws an exception, the object will not be fully constructed, and it won’t call the destructor. In that case, those resources allocated before the exception is thrown will be leaked.

In .NET, the garbage collector will call the Finalize() method (only if you provide the destructor) on the object to clean up its unmanaged resources. Therefore, by providing an implementation for the destructor, like ~A() {Dispose(false);}, you eliminate leaks of unmanaged resources. Of course, the time when this destructor is called is non-deterministic, and it takes longer for the Finalize() to be called.

In order to be able to step through your IL code with the DbgCLR debugger, will need to do the following:

• Build your project and create the .exe output file.
• Create .il file.
• Run the ildasm.exe MS .NET Framework IL Disassembler.
• Open .exe file.
• Dump (save As) .il file.
• Finish the round trip, create the .exe (PE format) and .pdb files.
• Run the ilasm.exe MS .NET Framework IL Assembler and specify the .il filename and/debug option.