The Exception.GetType() answer

Lots of good feedback and ideas… but here is the answer I got from the developers here..


Well, as with many odd things in the framework, it has to do with ComInterop; specifically ComInterop and backwards compatibility.  Don’t get me wrong, I love the features COM interop gives, but I don’t like its effect on the public surface area of the framework.    This little gem comes from the _Exception interface which Exception implements as of Whidbey.  In fact many of the COMVisible types in the BCL that had members added to them implement a _Xxx interface with just those members that were introduced in V1.0.  Note that class interfaces include not only all public methods on the class but all public methods on parent classes as well (such as System.Object). This was done to preserve backward compatibility with COM clients that worked against V1.0. 



Comments (2)

  1. Sean Chase says:

    Cool! As I responded in your last post, I saw the new interface (System.Runtime.InteropServices._Exception) being implemented in System.Exception. God bless that .NET Reflector tool! 🙂

  2. Because of this, I think that at some time, COM/Win32/etc should be made obsolete because otherwise, in time, a clean nice framework like .NET Framework will get as ugly as older frameworks.

    My view is that .NET (MSIL) binary code will at some point be run directly by hardware processors and Win32 will be emulated as DOS is now emulated on Win32. (Half joke, half dream). At that point, Windows kernel will be .NET-based itself so I hope you will know exactely all the points within .NET Framework which contain code included only to maintain compatibility to be able to remove it.

    I understand that for the moment compatibility with older versions/systems is crucial to Microsoft (and I agree from an economical point of view), but personally, I won’t exchange simplicity and elegance on backwards compatibility. That was exactely what made C++ "ugly" (Again, half joke) 🙂

Skip to main content