Designing great frameworks training: Rich Type System

Continuing on the weekly series, today we posted the session on A Rich Type System.  Thanks for watching the last week’s session on naming conventions and coming that chat… Last week we had over 90 people at the chat.   If you missed it there will be a chat transcript posted soon.   The technical content of the presentations are going to start ramping up fast from here on out. 


A couple of notes on this sessions:

I am interested in your thoughts on Value and Reference types.. do you agree with me that many developers on the platform can be very productive and happy on the platform without really understanding the distinction between value and reference types?  (slide 5).


Funny, listening to my self read code… for a line like: “int i = 123;”  I read that as “int i gets 123”.  I guess “gets” comes from my history with Pascal… how do you think it is mostly read?


I think it is very cool that you can look at the source code for int\Int32… it is just a value type, you could write one of your own.  Check it out int32.cs


Slide 16 talks about generics, sense I filmed this, we decided to added generics to the CLS in the .NET Framework 2.0 (Whidbey) time frame (before Longhorn). 


Slide 20 talks about the now infamous naming convention for generic type parameters.  Again, my data is out of date.  Kris has the latest guideline here.  I must say it is a bit odd to hear me vigorously defend our “old” K, V model… I must say I sound pretty convincing.  J  That said, I am very happy with the new model we have, I think it fits in much better with the overall model


Slide 27: The obvious question many of you will want to know is how to get a list of all the optimizations the JIT does.  The short answer is that we don’t produce such a list to ensure that we are free to change the JIT as we move forward and moves to different processorts.  The thing you should do in your code is to measure, measure, measure… don’t assume “smarter” code is better.  Write the code in the obvious, easy to read way, then measure and optimize.    More on this in Rico’s talk in the next few weeks.


Slide 27: I confirmed it, we do this optimization on accessing chars out of a string as well as arrays.  For all intents and purposes, the JIT treats instances of System.String just like a char[] for exactly this reason.


Slide 30: Good news on the catch{}, vs catch (Exception e) differences.  We are very likely going to address this in Whidbey.  That is we will wrap exceptions that don’t inherit from System.Exception in a class that does inherit from System.Exception…. Look for more data on this post Beta2.


Slide 36: First, an interesting thread on localizing for developers… Lots of good comments here:

Slide 36: Brian Harry and I recently spoke about error messages for exceptions.  He made a good point that sometimes end users to see exception error messages.  This is particularly true when you are building an end application. So for most “system” or “framework” level exceptions target the message at a developer, but for application specific exceptions expect for an end user to see them.

Slide 36: UE = User Education… they are the folks the write the documentation for the product.


Slide 56: Did anyone happen to use a very early, pre-beta release of the .NET Framework and actually see the PrinterOnFireException?  I would be interested to hear if anyone actually spotted this…


General question: how do you like the questions at the end?  Are they helpful for you to understand the material? 



Rich Type System
Learn what rich constructs from the CLR's type system are available and appropriate for developing APIs. Also, learn when to use reference over value types, delegates, exceptions, attributes, and many other important features.

 I will be in a chat room on 2/2 1pm PST to answer questions and hear your comments on this topic.  The Q&A part of these classes is always my favorite part; I hope you will take time to come.
[Sign up for the chat]


Sign up for coming chats…

2/4 - Member Types [Sign up for the post session chat]

2/11 - Designing Inheritance Hierarchies [Sign up for the post session chat]

2/18 - API Usability [Sign up for the post session chat]

2/25 - Designing Progressive APIs [Sign up for the post session chat]


Comments (33)

  1. Value and Reference Types: There is almost no distinction between the allocation and usage of a value or reference type in C# or VB. A lack of understanding is a recipe for disaster.

  2. Nicholas Allen says:

    Changing exceptions that don’t inherit from System.Exception into a class that does inherit from System.Exception…

    Isn’t it a little late to be making backwards incompatible platform changes like this?

  3. We are working on a plat to make this a compatible change. That is you could still “throw 42” and “catch 42”, but in between we’d wrap it in an exception.

  4. Nicholas Allen says:

    Right, that’d be very helpful. But before, these thrown objects would bubble through all of the code that just caught or filtered on System.Exception. There must be millions of consumers that catch System.Exception even if they’ve been told not to do that. Most of this exceptional case code is untested compared to the mainline code. During the time the objects are wrapped by an exception, they’ll hit all of these exception blocks that they didn’t used to.

  5. JD says:

    Nicholas, I think that’s kind of the point.

    Swallowing all exceptions, if that’s what you want to do, should swallow all exceptions.

    Those few non-CLS exceptions that you might have trickled by are by far the exception, and are generally not present in most applications. So the breaking aspect of this change is minimal, and in many of those cases, it actually fixes the behavior where the catch was intended to catch *all* exceptions.

    Is this a theoretical concern of yours, or is there a scenario that you know of where this will cause real problems? If it’s the latter, I’m sure that Brad would love to know the details.

  6. anon says:

    What is the point of Int32.DontTouchThis() ?

  7. Jonathan Pryor says:

    RE: wrapping exceptions in a System.Exception…

    This may impact compiler writers of non-traditional languages, such as Nermerle. Apparently they’d like exception performance to be faster than it currently is:

    One of the recommendations of a Mono developer was to use an exception type that doesn’t inherit from System.Exception, as less time is needed to fill the stack trace:

    Requiring that all exceptions thrown be a System.Exception limits the ability to perform such optimizations.

  8. Nicholas Allen says:

    JD, yeah I do have a specific scenario in mind. But that’s not really the point. Even if this kind of change gets announced on every .NET blog, only a tiny fraction of the development community will know about it to give feedback. Even if it goes on MSDN and gets sent to all the development mailing lists, it’s still a tiny fraction. Even if it’s on the front page of and Brad starts cold calling everyone who owns Windows, it’ll still only reach a tiny fraction.

    That’s why the bar for accepting breaking changes into the platform needs to be so high. Try to get OS to break compatibility unless you have a demonstrable security hole. They spend a ridiculous amount of time making sure things are precisely the way they were in the previous version. .NET/WinFX is supposed to be the step beyond Win32. The bar has to be just as high. I can’t just side-by-side every version of the framework ever released. It defeats the point of having a shared runtime.

    Anyways, the problem I have is a Java/.NET interop scenario. I translate Java to IL and run them together in a single process to avoid marshalling costs. Neither code base deals well handling the other’s exception types. That is, Java code can throw an exception, more Java code higher up the stack can deal with that exception, but intervening C# code can’t handle it. And vice versa. Previously this was not a big problem as java.lang.Exception was not descended from System.Exception, and obviously the opposite was also not the case. With this change, all of the Java exceptions will also appear to C# as its native exception type while in flight.

  9. About Int32’s DontTouchThis – here’s the method:

    #if _DEBUG

    private void DontTouchThis() {

    m_value = 0;



    Our C# compiler has some great logic for detecting unused fields. Unfortunately the compiler didn’t special case the base class library. We got compiler warnings when compiling Int32 and some other classes saying their internal m_value field either wasn’t used, or always had its default value of 0. The compiler warning here is an error (the field was there for suitable, base level reasons). Instead of disabling those warnings globally for mscorlib (which would have hidden problems in other classes) we ended up adding in these DontTouchThis methods to convince the compiler that we’re doing something with that field, to simply silence the compiler warning.

    Now we do have the relatively new #pragma support in the C# compiler, so we can disable these warnings on a finer grained level. However, we left many of the classes with the DontTouchThis method as-is, simply because of time. Since we don’t include the DontTouchThis methods in retail builds, we get almost no gain from doing this.

    Brian Grunkemeyer

    MS CLR Base Class Library team

  10. Matthew W. Jackson says:

    Wrapping non-exceptions in Exception objects seems like the wrong solution to the problem.

    It seems like it would be better if more languages (especially C#) supported catching anything, even if it isn’t allowed to throw anything.

    Why not add an extension to C# to allow it to catch object? It wouldn’t be of any use to a pure C# project, since you still couldn’t throw anything other than an Exception. And C# code interfacing with Java could catch java.lang.Throwable with no problem.

    What’s the harm in allowing a catch with any type?

  11. It really comes down to what kind of programming model do you want? The C# language spec is clear – all exceptions derive from System.Exception. Frankly I think that is a rationale language design and I would not push them to change it.

  12. Slide 52 incorrectly states that static classes have a private default constructor. Static classes don’t have any instance constructor at all, not even a private one.

  13. Barry Kelly says:

    Re: Slide 30: Good news on the catch{}, vs catch (Exception e) differences. We are very likely going to address this in Whidbey. That is we will wrap exceptions that don’t inherit from System.Exception in a class that does inherit from System.Exception…. Look for more data on this post Beta2.

    I really hope you don’t do this, and if you do you make it optional. Most other languages I’ve used (especially Delphi’s exception model) allow exceptions derived from non-Exception base types to prevent the exception being caught by "catch (Exception)".

    How are we meant to create exceptions that aren’t caught by catch (Exception)?

    As an aside, I believe ThreadAbortException should not be derived from Exception (irrelevant of why one should not use Thread.Abort()).

  14. Mattias, slide 52 is talking about how to define a static class in a languages that don’t support them with a keyword (for example VB or C# 1.0)… you can’t just not include a constructor there.

  15. Barry Kelly says:

    I know this is the wrong place to ask this, but I will anyway.

    Does anyone know how to download the video streams on that page ( to a standalone file that can be played without an internet connection? (Because my work machine has no sound, I have to bring media home with me on my pen drive to watch it, but I won’t be streaming video at home.)

  16. Fabian says:

    I’m not sure whether I just missed that bit, but did you really say that value types are allocated on the stack? I hope Jon Skeet doesn’t see this 🙂 [1]

    Also, I think you missed one of the most important things about value types, especially in the context of frameworks: cou can’t derive other types from them. (At least on the slides, you didn’t mention that. My connection sometimes broke down, so I skipped some of the audio.)

    As to how "int i = 123;" is commonly read: I usually read the "=" as "ist gleich"…


  17. Ray says:

    it would be nice to download these sessions to watch offline. They dont have internet on the train yet…

  18. Ray — yup, you are right, we are working on a plan to make them downloadable now…

  19. Mark Gantlett says:

    "Also, learn when to use reference over value types, delegates, .."

    I was hoping to hear from you on delegates. It was menchioned in the presentation description. May be in a future show you could brief on it?

  20. Good point, sorry for the false advertising.. we talk about them briefly in member types (around events)… but not in depth… what were you hoping to learn?

  21. Mark Gantlett says:

    I’ve not used delegates yet just been reading up on them this past week. Was just wanting to hear from you best practices in general. When to use, when not to…

  22. Moe says:

    Any chance you could post the total length of each presentation somewhere so I’ll know how long I need to set aside?

  23. Good idea, I just talked to the MSDN folks and they are going to add it.

  24. Chris Haas says:

    First, the couple of sessions I saw were really great and informative, especially since I started using FxCop recently.

    Second, am I right in thinking that all of these sessions have already taken place? If so, is there some reason why we have to wait a week between each session? I’ve got a full day here that I’d love to just sit back and watch a bunch of these.

Skip to main content