Compiler Error Messages

I've spent a fair amount of time lately tweaking the C# compiler's error messages.  At some point I begin to wonder, how clearly do we have to spell things out for end users?  There are at least 2 dozen different error messages that could be summarized with just “not an l-value”.  Now granted, there is an extreme.  Some compilers and tools do little more than tell you an error happened, and sometimes where it happened.  I believe an error message should indicate what is wrong, and if possible how to fix it.  So my question for anybody who reads this an actually uses C#, do you feel like the compiler error messages are good or bad?  If you can give me specific examples maybe I can get a few things fixed before we ship ;)

--Grant

Comments

• Anonymous
  February 28, 2004
  The comment has been removed
• Anonymous
  February 28, 2004
  In this case, it's better to add than to remove.
  Some of the starting developers where I work, who had experience with VC++ 6 enjoy them a lot.
  
  Why do you even consider removing this?
• Anonymous
  February 29, 2004
  Grant,
  
  Probably the most confusing for new C# developers -- whether they have an extensive background in C++ or not -- has to do with the famous Unknown type message, (paraphrase) "Have you forgotten an assembly reference or using directive?". C++ developers in particular get stumped 'cause they're used to having 2 different sets of errors: one group from the preprocessor/compiler, and another group from the linker. And if they're new to C#, they don't get it that metadata is resolving both the #include and linker issues.
  
  Of course, when this error occurs, you're not gonna know which problem it is: you only know that you can't resolve the type that they're referencing. But experience teaching .NET has shown me that more of the time the problem is the lack of an assembly reference. So perhaps a better msg might suggest that they first check their assembly references, and if those are complete, then to try using the fully qualified name or add a using directive?
  
  If you wanted to get really clever, a way to optionally list all the friendly names of the referenced assemblies and all the using directives that are in scope could be interesting, but it'd have to be optional: once they get comfortable, they'd hate that (I would!).
  
  Hope this helps.
  RHS
• Anonymous
  February 29, 2004
  The one I'd like to be fixed/added is using debug info of referenced assembly (if any) when showing related point. For example, I have 2 assemblies, one have interface defined and second one uses that interface. If you don't implement all members of interface, it correctly shows error, but it gives useless reference:
  
  CorePhone.cs(10,15): error CS0535: 'Core.Phone' does not implement interface member 'Framework.ICoreObject.Modified'
  CorebinDebugFramework.dll: (Related file)
  
  However, if related position were in same assembly, it gives correct source point.
• Anonymous
  February 29, 2004
  As a C++ programmer I think the C# compilers error messages are good.
  
  However people from a VB background think they are not very helpful.
  
  You should however be able to do a LOT better then a C++ compiler, keeping an ex c++ programmer happy is a VERY low bar!
  
  I do not mind if you need to “rerun” the compiler when you find an error, so as to get enough information for a useful error message. You only have to be fast in the case were the code has no errors.
  
  E.g. if I use the wRong case for a method name, you should be able to tell me the name of the method(s) that matches on all but case. If I misspell a method name, you should be able to list “close” method names. Likewise for class names. If the class I use is not find due to a missing #using, you should be able to list all namespaces that constrains a class with that name.
  
  
  ringi at bigfoot dot c0m
• Anonymous
  February 29, 2004
  Grant,
  
  As the compiler needs to cater to beginning and advanced C# programmers, so does the error message need to have several levels.
  A basic one that will probably have enough information for 90% of the cases, but when you go to the details of the message there is additional info.
  
  Mark
  
• Anonymous
  March 01, 2004
  The one error message that comes to mind is CS0104: ambiguous reference. The compiler displays the relevant locations, but it should also display the fully qualified names.
  
  The Visual Studio task list is even worse: it only displays 'X' is an ambiguous reference, without an indication of which types it could refer to.
• Anonymous
  March 01, 2004
  I see a lot of good suggestions here about what the compiler should spit out. I don't think that I can add any suggestions as to WHAT to spit out, but I have one on HOW to show it.
  
  Why not create an XML schema for compiler messages and output XML that conforms to that schema? In it, you could have an error code, an error description (localized or non), a pointer to a link with more information on the error, suggestions, pointers, etc, etc.
  
  And then this would be great for tools like MSBuild, because we could just process the output very easily (with .NET or any other programming language practically). It definitely beats a custom format and opens up the compiler output for extensibility, IMO.
• Anonymous
  March 03, 2004
  Hmmm, I'd just be able if the errors/warnings were listed in order of occurrence in the task list instead of whatever order they are in (alpha?). I'm pretty happy with the quality of the messages even if they are a bit long. I am happy to see that in Whidbey we might get multiline display of error messages cool. And before someone mentions it, I do know how to turn off the auto-display of the task list window after a build with errors. I just find too many other developers tripping up on attacking what they think is the first error and wasting time because that error is a side effect of the real first error.
• Anonymous
  March 03, 2004
  Oops. That should've read "I'd just be happy if the errors/warnings ..."
• Anonymous
  March 10, 2004
  The comment has been removed
• Anonymous
  May 03, 2004
  The comment has been removed
• Anonymous
  May 03, 2004
  The comment has been removed
• Anonymous
  June 04, 2004
  The comment has been removed
• Anonymous
  July 10, 2004
  Connie,
  
  Unexpected end of file usually indicates a missing closing brace, semicolon, ), etc.
  
  for example,
  public class xyz
  {
  public void method()
  {
  return;
  }
  
  A closing brace is missing. I close method() but not xyz(), although the indentation makes it look as if xyz is closed.
  
• Anonymous
  July 10, 2004
  The above post may make more sense if the indentation appears correctly, so here is another shot:
  
  public class xyz
  {
      public void method()
      {
          return;
  }
• Anonymous
  July 10, 2004
  Oh well. It was worth a shot.