Numbering compiler error messages?

[froglegs]

On Saturday, 29 March 2014 at 15:37:05 UTC, w0rp wrote:
> I agree with Walter about error numbers being a bad idea. 
> Especially when people prefer the numbers over a description. 
> MySQL has really turned me off the idea of error numbers. When 
> I get an error about MySQL syntax, the message actually reads 
> like this.
>
> "Error near <snippet> <line number> <column number> ... <error 
> number>"
>
> It never tells you what kind of syntax error you made, or 
> *exactly* where it actually happened (The line and column 
> numbers are misleading.). You just get a message "well it 
> broke" and an error number which might as well be the result of 
> a hash function. As a result, I hardly ever look up the error 
> number, and I just make a guess as to what I did wrong. It's 
> usually faster to guess.
>
> It's kind of like the effect bug IDs can have on commit 
> messagses, which I mentioned in another thread. If you put some 
> ID you can search for in a message, some people have a tendency 
> to rely on the ID and forget about providing a descriptive 
> message as well.
>
> I think a better approach is to just describe the error better. 
> When I use DMD I get some pretty good results already for 
> errors. We just need to patch messages which may be confusing 
> at the moment into being more descriptive.

   The way Visual C++ does it is that you get *both* and error
number and an error message.  Having the error number is very
useful for googling(yes the complete message will give you hits,
but the # is more concise and turns up more hits), and for
quickly referring to a given error.