Thursday, February 8, 2007

Error Messages

Some compiler error messages are just painfully bad. One of the great things I like about the members of my research group is that, for programming language people, they are particularly concerned with use-ability. In particular, I'll often hear them discussing how a certain technique is naturally pre-disposed to have bad error messages and therefore maybe isn't worth pursuing. Alternatively, sometimes we'll talk about how to coax better error messages out of one of our research tools. This is good, because the error messages produced by research tools and more formal CS-y things are often quite bad. See the Standard ML of NJ compiler for good examples.

But one thing that never ceases to amaze me is how bad the GNU C++ compiler's error messages can be. Why does this amaze me? Well, presumably GNU C++ is one of the compilers that is mostly frequently used by developers who "just care about writing working code, not messing with all that formal mumbo jumbo." Case in point, the following error message:
NelsYield-Instrumented.cxx:12: error: new types may not be defined in a return type
Okay, this doesn't seem too bad. But first, oh compiler, wouldn't it be helpful to tell me which type is the 'new' type you think that I'm declaring? Regardless, I know enough about what's going on to know that the error is not in using an undeclared type (the type is included in the header file that I #include) but rather somewhere else in the process. This isn't the best example of bad error messages from g++, it was the closest one at hand, but I personally have seen much worse, much less helpful messages. Just like SML, the error message never seems to actually tell you what the problem is, and you end up being Mr. C++ detective. Java is a dream by comparison. Anyway, just a little venting... not really sure where I'm going with all of this.

Update:
Natuarlly, I was missing a semi-colon at the end of my class definition. C++, I hate you will all of my being.

2 comments:

  1. The main reason it is hard for ML compilers like SMLnj to have good error messages is type inference. An "error" might be the result of a mistake made way earlier in the program that made the compiler commit to a particular incorrect type for some value which later results in an un-typable use of that code. C++ certainly doesn't have the same excuse.

    Not sure if you are aware of it or not, but there is work on generating better error messages for both ML-like languages (OCaml) and C++ at the University of Washington.

    ReplyDelete
  2. Oh yeah I know. I totally understand why ML has this problem and in fact I (most of the time) believe that type inference is worth it. As far as I understand, type inference works a lot like a constraint solver, and when several constraints are contradictory, it's hard to point out which one is wrong. (Is that a fair description of the problem?)

    Anyway, I am looking at this more from the other perspective. If someone weren't willing to use SML because of its so-so error messages, I would politely point out the fact that g++'s error messages also leave a lot to be desired. C++ is a (overly) complex language, and I believe this has a lot to do with the quality of error messages that its compilers produce.

    ReplyDelete