is dispose called when exception occurs in ctor?

[Symbai]

Let's say I have some code like this:

try
{
	using var bla = Foo(some_byte_array);
	// some stuff here
}
catch () { }


class Foo : IDisposable
{
	IntPtr AllocationHandle;
	
	public Foo(byte[] buffer)
	{
		//do some allocation with AllocationHandle here
		
		throw new Exception();
	}
	
	public void Dispose()
	{
		//free AllocationHandle here
	}
	
}

Is .NET runtime calling Dispose so my handle gets freed?

[elgonzo]

No, Dispose is not called in this situation. If you can't ensure that Dispose is called under any and every circumstances (which is often the case), look into using SafeHandle instead of IntPtr/nint. If you can't use SafeHandles for some reason and stick with IntPtr/nint, then implement a finalizer and the Dispose pattern (Visual Studio can generate the skeleton of this Dispose pattern)

Note that your using statement is semantically equivalent to

{
    Foo bla = new Foo(some_byte_array);
    try
    {
        // some stuff here
    }
    finally
    {
        ((IDisposable) bla)?.Dispose();
    }
}

(see also the C# language spec: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/statements#1314-the-using-statement)

When Foo bla = new Foo(some_byte_array) is throwing, the (semantically equivalent) try-finally won't be entered, hence no call to Dispose.

[Symbai]

And with this its guaranteed to be called if the exception occurs in the constructor?

[elgonzo]

I don't understand. The this keyword is unrelated. How/why do you think that the this keyword might matter here? Scratch that. I misread your comment and didn't notice you used "this" only as an anchor for a link to an article about finalizers...

Yes. The finalizer is guaranteed to be run (once the GC comes around to collect and process the finalization queue).

Because, for the ctor to be executed, the instance itself has to already exist (otherwise you wouldn't be able to access instance members or use the this keyword in ctors). Once an instance of a type with a finalizer exists and cannot be accessed by any possible continuation of execution (other than the running of finalizers themselves), that instance becomes eligible for finalization. Throwing in a ctor (there is a distincion here between an instance existing and a ctor completing successfully) results in the instance not being accessible by anything due to the new expression not returning a value (it throws instead). Hence why throwing in a ctor makes a finalizable instance instantly eligible for finalization. [EDIT: "Instantly" might be poor wording, see my comment below]

[elgonzo]

That said, if you were to use SafeHandle instead of IntPtr/nint, you could avoid needing a finalizer, as SafeHandle's themselves are finalizable types. (You should still use Dispose for timely release of the SafeHandles, because otherwise it's left to the whims of the GC as to when the SafeHandles are released.)

[elgonzo]

One more small update re my statement that when a ctor of a finalizable instance throws it becomes instantly eligible for finalization. This doesn't seem to be entirely correct. It shouldn't matter much in practical terms, but still... If the following is too technical or too noisy for your liking, just pretend i didn't write "instantly" in my answer. 😅

Based on observations on some limited experiments, the finalizable instance in question only becomes eligible for finalization once the method who executed the new expression returns/exits. (Not sure whether this is observable across different .NET versions; i have only tested with .NET 8.)

For example, given a finalizable type like this silly type:

public class Kaboom : IDisposable
{
    private int _v;

    public Kaboom(int v)
    {
        _v = v;
        if (v == 0)
            throw new Exception();
    }

    public void PrintValue() => Console.WriteLine($"Value is {_v}");


    public void Dispose()
    {
        Console.WriteLine("Dispose called");
    }

    ~Kaboom()
    {
        Console.WriteLine("Finalizer called");
    }
}

and it is then tried to observe Kaboom's finalizer being called like so:

static void TestKaboomFinalizer()
{
  try
  {
      using var k = new Kaboom(0);        // throws
      k.PrintValue();
  }
  catch
  {
      Console.WriteLine("Oopsie...");
  }
  
  for (int i = 0; i < 10; ++i)
  {
      GC.Collect();
      GC.WaitForPendingFinalizers();
  }

  Console.WriteLine("TestKaboomFinalizer method exits.");
}

the loop at the end forcing garbage collection won't necessarily result in the created but inaccessible Kaboom instance being finalized. You would see the output "TestKaboomFinalizer method exits." without the Kaboom instance being finalized yet.

However, once the TestKaboomFinalizer method exits, the inaccessible Kaboom instance becomes eligible for finalization:

static void ThisWillObserveFinalizationOfKaboom()
{
  TestKaboomFinalizer();

  for (int i = 0; i < 10; ++i)
  {
      GC.Collect();
      GC.WaitForPendingFinalizers();
  }

  Console.WriteLine("ThisWillObserveFinalizationOfKaboom method exits.");
}

Here, you would see the Kaboom instance being finalized before the output "ThisWillObserveFinalizationOfKaboom method exits.".

It doesn't seem to matter whether the assignment is to a local variable, a field or some other storage location like in an array or other collection. It kinda seems to be related to the current stack frame at the time the instance is being created and its ctor throws. Because if you replace the new expression in the TestKaboomFinalizer method with a call to the Activator.CreateInstance method (which then would establish its own stack frame(s)):

        using var k = (Kaboom?) Activator.CreateInstance(typeof(Kaboom), 0);        // throws
        k?.PrintValue();

you will be able able to observe the Kaboom instance being finalized before the TestKaboomFinalizer method exits. Them damn nuances... 🤪