Channel 9 - Discussions by DinoViehland http://mschnlnine.vo.llnwd.net/d1/Dev/App_Themes/C9/images/feedimage.png Channel 9 - Discussions by DinoViehland http://channel9.msdn.com/Niners/DinoViehland/Discussions Channel 9 keeps you up to date with the latest news and behind the scenes info from Microsoft that developers love to keep up with. From LINQ to SilverLight – Watch videos and hear about all the cool technologies coming and the people behind them. http://channel9.msdn.com/Niners/DinoViehland/Discussions en Wed, 19 Jun 2013 19:15:24 GMT Wed, 19 Jun 2013 19:15:24 GMT Rev9 0 0 0 Tech Off - is 'new object().property' or 'new object().method()' a good idea?
littleguru wrote:


The MyObject instance won't be collected by the GC if you are accessing any fields that held by that instance... otherwise - as said - it would be a heavy CLR (GC) bug!


Just to shed a little light on the situation the typical example of this is using IntPtr's and the Dispose pattern.  Such as:

class MyDisposable : IDisposable {
    private IntPtr _foo;
    public void DoIt() {
        SomePInvokeOperation(_foo);
    }

    ~MyDisposable() {
        Dispose();
    }
    public void Dispose() {
        CloseMyHandle(_foo);
        GC.SuppressFinalization(this);
    }
}

Now you do: new MyDisposable().DoIt();  The IntPtr is read and right after that read there are no longer any references to the MyDisposable() instance.  Before SomePInvokeOperation can run the GC kicks in and collects the MyDisposable class.  Next the finalizer thread runs which runs the finalizer which closes the native resource.  Finally your SomePInvokeOperation runs and is operating on a _foo that is no longer valid.

The worst case scenario here is that you can use this for a handle recycling attack which violates security.  If you're lucky the app is just going to crash.  Anyway, the way to fix this is to put a GC.KeepAlive(this); in DoIt() so that the object survives the lifetime of the call.  But it's really only a problem when you're interacting with native resources which the GC doesn't understand and keep alive its self.  So still not a bug, but a good thing to know about if you're doing any interop programming.

]]> http://channel9.msdn.com/Forums/TechOff/259414-is-new-objectproperty-or-new-objectmethod-a-good-idea/42fa4b4480bf4ac0a7db9dfa00865c30#42fa4b4480bf4ac0a7db9dfa00865c30 Tue, 04 Dec 2007 03:28:33 GMT http://channel9.msdn.com/Forums/TechOff/259414-is-new-objectproperty-or-new-objectmethod-a-good-idea/42fa4b4480bf4ac0a7db9dfa00865c30#42fa4b4480bf4ac0a7db9dfa00865c30 DinoViehland 41 http://channel9.msdn.com/Niners/DinoViehland/Discussions/RSS Tech Off - Doing the same thing for multiple exception types The first and last forms are the best.  The middle one is actually different from the VB one. 

The key here is the the difference between catches, finally's, and filters and when they run.  There are two passes to exception handling (http://blogs.msdn.com/cbrumme/archive/2003/10/01/51524.aspx).  The catch runs on the 2nd pass, but the filter (the when clause in VB) runs on the 1st pass - that's also where finally's run.  Catching an exception (interrupting the 1st pass) and rethrowing is generally considered bad.  For example you interrupt the debugging experience and you raise a 2nd exception (and exceptions aren't cheap).  There's probably other reasons out there as well.

So 1 or 3, never 2.

]]> http://channel9.msdn.com/Forums/TechOff/258486-Doing-the-same-thing-for-multiple-exception-types/2ff568485acf4e60b27c9df901039755#2ff568485acf4e60b27c9df901039755 Thu, 25 Oct 2007 03:58:12 GMT http://channel9.msdn.com/Forums/TechOff/258486-Doing-the-same-thing-for-multiple-exception-types/2ff568485acf4e60b27c9df901039755#2ff568485acf4e60b27c9df901039755 DinoViehland 24 http://channel9.msdn.com/Niners/DinoViehland/Discussions/RSS