Error Number Trivia

Have you ever wondered how we come up with the error and warning numbers?  Well if you've looked at the SSCLI source for the C# compiler, you'll see that we use a file full of macros to define the error numbers, their severity, and the resource ID that has their text (errors.h).  Now like most version control systems ours has a hard time merging changes that are too close to each other.  So to prevent such conflicts each of the C# compiler developers was assigned ranges, and as long as we stuck to our ranges, we never had problems.  I started here at Microsoft well after the compiler was started, so I got the highest range starting at error CS1500.  My most recent addition was error CS1715.  Now there are some blanks or holes in the numbering.  That usually comes from adding an error or warning, and then later removing it (all between releases so your lucky customers never saw it).  I doubt anybody will ever go back an reuse those numbers, at least not until we run out of 4-digit numbers.

There are a few exceptions to these rules.  Originally the command-line driver (csc.exe) did not share errors.h with the compiler (cscomp.dll).  And that worked for a while, but became too cumbersome, so we moved it's errors into the same file and moved all of it's error numbers to start at 2000 and up.  You'll also see one special error message: error CS2018.  It has no corresponding resource ID.  Why?  Because it is the error the compiler reports when it can't find any resource DLL, and thus can't load any strings.  So that one single error message will never be localized, and will always be hard-coded in the driver (csc.exe).

The last notable section are the CLS errors and warnings that start at 3000.  First of all, I added most of those errors, so there wasn't much problem of merging.  Secondly CLS checking was not always part of the compiler.  When we did add it the Frameworks team had already written a ton of code that violated a ton of the rules.  So they wanted a way to have the compiler tell them about the problems but not break the daily build.  So we added  special temporary switch that would force all of the errors in the 3000 range down to warnings.  They used that switch until they had enough time to fix all of their code, and then we removed the switch.

How many of you ever look in the docs (inside VS or online at MSDN) for extra help on specific error messages or warnings?  Our UE team likes to have a sample that reproduces the error or warning with a comment or another sample that shows how to fix it or work-around it.  I personally don't think the first sample is all that useful (except for maybe setting the stage for the second sample).  It just seems to me that if you've hit an error message, you don't need another sample of another way to cause the error, you just need a sample of what to do right.  I am partly asking because right now the UE guys are asking me for samples for most of the new errors and warnings I've added.

--Grant

Comments

• Anonymous
  March 12, 2004
  I like the sample error myself. Sometimes I can see how my code looks like the sample. The sample helps explain the cause of the error by example.
• Anonymous
  March 12, 2004
  The samples of the error-causing code are helpful to better understand what it was you did wrong. I know the one or two times I ran into compiler errors that confused me, I appreciated both samples.
• Anonymous
  April 07, 2004
  asdasdsadas