The Exception.GetType() mystery

Spelunking through the Framework one day, I noticed that, new in Whidbey, System.Exception has this method:

        public new Type GetType(){
                   return base.GetType();

Wow, how odd I thought.  Adding a newslot to re-define Object’s GetType method then just returning the result of a call to Object.GetType ().  Too odd, I thought, it has to be a bug, so I checked with the developer and nope, no bug… Any guesses why we did this?


I’ll post the answer at end of day today…

Comments (8)

  1. Steve Saxon says:

    Its because of a bug in .NET remoting…;en-us;320347

    What I don’t understand is why the Whidbey dev put in the workaround rather than simply getting the underlying issue fixed.

    I guess *everything* will be put right in Longhorn 🙂

  2. Brad Abrams says:

    That is a good issue, but not the reason we made this change… As far as really fixing this, all I can say is look forward to Indigo!

  3. Steve Saxon says:

    Perhaps stranger still, this same "feature" has been in .NET for a long time… For example, you can see it in the AppDomain in the Rotor code, dated April 14, 1999.

    Kind of makes me think its not likely to get fixed, and its just another of those "you just have to know" to get the most of your .NET investment – kind of like the MemoryBarrier workaround for the double-check lock pattern…

  4. Sean Chase says:

    Perhaps something to do with System.Exception implementing System.Runtime.InteropServices._Exception, or the code in System.Object.GetType() being different in 2.0?

    Just playing around with Reflector. 🙂

  5. You could insert malicious code inside an overridden GetType()

    which is called by runtime with no CAS ?

    Just a guess

  6. Dmitriy Zaslavskiy says:

    Just to add the comment above.

    C# generates this methods automatically because Interface method

    in this case _Exception.GetType() needs to be implemented in a class by a virtual function but Object.GetType() is not virtual.

    C# doesn’t have the requirement for a method implementing interface method to be virtual, so it plays a trick:

    If the code is in the same module it will simply silently mark the method as

    newslot virtual final (final is to make sure not break the meaning of non-virtual method).

    When methods satisfying the interface are in the base class it would create this fake virtual method.

    Finally when base class is in a different module it will create private implementation with the newslot virtual final flags and forward the call to base.

    I could have gotten something wrong.

    And I also remember that implementation of this trick changed somewhere between v1.0 and v1.1 or even v1.0 and v1.0SP2+

  7. Brad Abrams says:
  8. Merak says:

    You mean there were no comments explaining why the code was there?


Skip to main content