On 03/28/2014 09:32 PM, Brad Anderson wrote:
>>
>> The quality of error messages is always a problem, but numbers won't
>> fix that. (Been there, done that, too. Numbering doesn't clarify things.)
>
> I think we'll just have to agree to disagree on that point. I've found
> VC++ error numbers invaluable whenever I confront a confusing error.
> There are often examples of what cause the error and how to fix it.

Well, invest the time saved on maintaining numbers to improve the error message thus making it less confusing.

On 3/28/2014 3:33 PM, Kapps wrote:
> you'd have to parse the error message in the first place which immediately makes it
> not practical and defeats the benefit of error codes.

It's not necessary to parse the error message. Just do a strstr() on it, that's enough to uniquely identify all of them.

On 3/28/2014 1:32 PM, Brad Anderson wrote:
> I think we'll just have to agree to disagree on that point. I've found VC++
> error numbers invaluable whenever I confront a confusing error. There are often
> examples of what cause the error and how to fix it.

And why doesn't grepping on the text of the error message work?

BTW, I often encounter perplexing messages from Linux, and I just plug the text into google.

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.

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.

On Saturday, 29 March 2014 at 07:34:21 UTC, Walter Bright wrote:
> On 3/28/2014 1:32 PM, Brad Anderson wrote:
>> I think we'll just have to agree to disagree on that point. I've found VC++
>> error numbers invaluable whenever I confront a confusing error. There are often
>> examples of what cause the error and how to fix it.
>
> And why doesn't grepping on the text of the error message work?
>

grepping what? Surely you don't mean the dmd source code.

> BTW, I often encounter perplexing messages from Linux, and I just plug the text into google.

Yeah, that's precisely how I solve a large portion of my problems
(both while programming and with life in general). I guess the
important point isn't to have error numbers necessarily but to
have one place where people can read more about an error and
share helpful information about an error. When you google dmd
error messages you'll often get ancient D1 forum posts that don't
necessarily apply anymore and you have to weed through a half
dozen different posts before you find some answers.

Perhaps a good compromise would be for errors that are complex
and can't easily be explained in the terse error message there
could be a url on the end that takes the user to a page on the
site or wiki where they can read more. Then only a subset of
errors, the ones that are particularly tricky, must be maintained.

On Saturday, 29 March 2014 at 17:12:45 UTC, froglegs wrote:
> 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.

Yeah, exactly. You wouldn't lose the short error descriptions.
That'd be absurd.

On Saturday, 29 March 2014 at 00:27:36 UTC, Martin Nowak wrote:
> On 03/28/2014 09:32 PM, Brad Anderson wrote:
>>>
>>> The quality of error messages is always a problem, but numbers won't
>>> fix that. (Been there, done that, too. Numbering doesn't clarify things.)
>>
>> I think we'll just have to agree to disagree on that point. I've found
>> VC++ error numbers invaluable whenever I confront a confusing error.
>> There are often examples of what cause the error and how to fix it.
>
> Well, invest the time saved on maintaining numbers to improve the error message thus making it less confusing.

I think those are two different problems though. Better error
messages are certainly a good thing that everyone agrees with.
Error numbers solve the problem of keeping error messages brief
while giving the user a way to lookup more information about it.

For example, in VC++ if you get "C2001 newline in constant" you
can just lookup C2001
http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx and there
is a long description of exactly why this error occurs along with
examples of code that can cause the bug and code that fixes the
bug. You aren't going to include all of that in an error message.
Experienced programmers see "newline in constant" and immediately
know the mistake from experience but an new programmer might see
that and think it has something to do with the "const char*"
portion of the line. If you click around other errors in the MSDN
link you'll see they do this for pretty much every error.

I'm convinced it's not worth it for every error but for some of
the more confusing ones that require a longer explanation than
would fit on the command line comfortably it'd be nice to have
somewhere on the wiki that can be linked for people to read more
about it.

On 3/29/2014 10:12 AM, froglegs wrote:
> 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),

More hits? How is that possible?

On 3/29/2014 10:45 AM, Brad Anderson wrote:
> On Saturday, 29 March 2014 at 07:34:21 UTC, Walter Bright wrote:
>> On 3/28/2014 1:32 PM, Brad Anderson wrote:
>>> I think we'll just have to agree to disagree on that point. I've found VC++
>>> error numbers invaluable whenever I confront a confusing error. There are often
>>> examples of what cause the error and how to fix it.
>>
>> And why doesn't grepping on the text of the error message work?
>>
>
> grepping what? Surely you don't mean the dmd source code.

Grepping whatever data you are searching for an explanation in.


> When you google dmd
> error messages you'll often get ancient D1 forum posts that don't
> necessarily apply anymore and you have to weed through a half
> dozen different posts before you find some answers.

That wouldn't change with error numbers. What you can do is limit the search to the spec. And, having a page with "error messages explained" can be created and then use search within that page - this is exactly as effective as having a page with "error numbers explained".


> Perhaps a good compromise would be for errors that are complex
> and can't easily be explained in the terse error message there
> could be a url on the end that takes the user to a page on the
> site or wiki where they can read more.

As mentioned earlier, I'd love to do urls, but,

1. user visible urls are terribly ugly to emit to the console
2. consoles don't support clickable urls
3. consoles don't support hypertext links