1

Both variables userManager and signInManager are class-level instance members that could be instantiated, or could be null.

Is it safe to replace this:

protected override void Dispose(bool disposing)
{
    if (disposing)
    {
        if (this.userManager != null)
        {
            this.userManager.Dispose();
            this.userManager = null;
        }

        if (this.signInManager != null)
        {
            this.signInManager.Dispose();
            this.signInManager = null;
        }
    }

    base.Dispose(disposing);
}

with this:

protected override void Dispose(bool disposing)
{
    if (disposing)
    {
        this.userManager?.Dispose();
        this.signInManager?.Dispose();
    }

    base.Dispose(disposing);
}

Personally I don't see the point in explicitly assigning the variables to null after disposing them, as they are not static, as far as I am aware, it doesn't do anything.

BartoszKP
  • 34,786
  • 15
  • 102
  • 130
PeteGO
  • 5,597
  • 3
  • 39
  • 70
  • The Dispose() method may be called more than once. In some cases it is very common, classes that derive from Stream. Does it still work? If it doesn't then it is not safe. – Hans Passant Sep 05 '15 at 23:36
  • I'd imagine `?` is just a syntactic sugar. Probably generates the same code as above. As for assigning null: that's a good question. Does that make any difference to GC at all? (I'm curious too, but I'm guessing it does, especially if your class has a finalizer) – mtmk Sep 05 '15 at 23:47
  • `null`ing the variables removes references between objects, so theoretically relives the GC - smaller graphs, less cycles, lower chances for unnecessary promotion to gen+1, etc - but unless you have myriads of those objects and unless you create&gc them very often, you will probably not notice performance difference. I personally like to `null` them just to make the `Disposed` state "more distinctive" - not all accompanying objects throw `ObjectDisposedExcpt` when left behing, OTOH `NullReferenceExcpt` is guaranteed. But that depends.. sometimes nullreference is misleading – quetzalcoatl Sep 05 '15 at 23:47

2 Answers2

0

The code is safe in the sense that it can't throw null reference exceptions. It's not 100 % equivalent though, for that you still need to set the references to null after disposing. This probably isn't critical, but in some cases it can help the garbage collector if the containing object stays in scope after being disposed.

this.userManager?.Dispose();
this.userManager = null;
this.signInManager?.Dispose();
this.signInManager = null;
sara
  • 3,521
  • 14
  • 34
  • did you mean `ref IDisposable memeber`? – quetzalcoatl Sep 05 '15 at 23:41
  • Interfaces are reference types, so is that really necessary? Either way, thinking about it I'd probably not create such a method unless there are a ton of members that need disposing. – sara Sep 05 '15 at 23:43
  • 1
    After your comment, I'd -1 it.. but then, here's 2:00AM on my place so maybe in your timezone you're tired already too.. There is a huge difference between "reference type"/"value type" (class/struct) and "passing by ref"/"passing by value"(ref/no ref) in the parameter list. Did you ever try assigning new values to method's parameters like in that code? If not, please do try, and please observe how callee's value **don't change** until `ref` is added. – quetzalcoatl Sep 05 '15 at 23:55
  • Welp, you're absolutely right, I blame the weather. Removed the non-working part, but the rest still holds. – sara Sep 06 '15 at 16:53
0

This has been Answered

You do not need to set a object to null. when you are disposing a object it will be handled by the GC (Garbage Collector)

Community
  • 1
  • 1
SamFromDeath
  • 21
  • 5