www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Numbering compiler error messages?

reply Johannes Pfau <nospam example.com> writes:
An idea stolen from C#:

How about adding a small 'error-message ID' like DPL00042 to every
compiler message? This makes it easier to search for information about
the error. If tools want to handle certain compiler errors then
they can grep for the message-ID instead of the complete message.

I thought of adding a wiki page, wiki.dlang.org/Compiler_Messages to
keep a list of all messages. It's then possible to add examples,
detailed information how to resolve an error and links to further
information (e.g. changelog entry for error/warning/deprecated message)
to that page.

I could file a pull request which does this for all existing error
messages, but it requires contributors to follow a small protocol
for future error messages as we need to make sure we do not assign one
ID to different messages:

If you want to introduce a new error message:
Before even opening a pull request, 
* go to  wiki.dlang.org/Compiler_Messages
* pick next free ID 
* add it to the page with status pending
* Once stuff is merged update the description/status on the wiki page

As an example how this could work, search for CS1002.
So do we want this?
Mar 28 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2014 1:23 AM, Johannes Pfau wrote:
 As an example how this could work, search for CS1002.
 So do we want this?

I've done this before. Short answer, it's a pain and doesn't really help. Searching is easy, just type in the message that was displayed, sans the variable part. I do it all the time.
Mar 28 2014
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 I've done this before. Short answer, it's a pain and doesn't 
 really help.

Since last time we have discussed this topic I have a better answer: It's a psychological thing: numbering things push people to count them and write down a piece of information (like a wiki page) for each number. Currently there is no complete dictionary of D errors/warnings/dips. This advantage alone seems enough to me to justify numbering them. Bye, bearophile
Mar 28 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2014 2:09 AM, bearophile wrote:
 Walter Bright:

 I've done this before. Short answer, it's a pain and doesn't really help.

Since last time we have discussed this topic I have a better answer: It's a psychological thing: numbering things push people to count them and write down a piece of information (like a wiki page) for each number. Currently there is no complete dictionary of D errors/warnings/dips. This advantage alone seems enough to me to justify numbering them.

As I've said, I've done this before. Those lists get just as out of date and unmaintained whether they are numbered or not.
Mar 28 2014
prev sibling next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Friday, 28 March 2014 at 09:04:00 UTC, Walter Bright wrote:
 On 3/28/2014 1:23 AM, Johannes Pfau wrote:
 As an example how this could work, search for CS1002.
 So do we want this?

I've done this before. Short answer, it's a pain and doesn't really help. Searching is easy, just type in the message that was displayed, sans the variable part. I do it all the time.

I think we could maybe find a middle ground? Not every error needs numbering, but having the more common ones "named and tagged and explained" could always help? I'm thinking things like: - expression has no effect in... - cannot default initialize... - dangling else... - empty if/for/while statement... It would really benefit the newer users that hit the error, to have a direct link explaining how things work in regards to that. It doesn't have to be a number. A simple (shortened) link to the wiki could also work. Or simply a formalized error name "Invalid default initialization Error: Custom error message here" A good argument in favor of that is that *you* would merely add the link in the compiler, and the community could document and explain the error. Well, I'm just throwing that out there.
Mar 28 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2014 2:23 AM, monarch_dodra wrote:
 Well, I'm just throwing that out there.

I've thought many times that an error message should be a clickable link. But until console displays support clickable text, it's just a fantasy.
Mar 28 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-03-28 19:09, Walter Bright wrote:

 I've thought many times that an error message should be a clickable
 link. But until console displays support clickable text, it's just a
 fantasy.

There are other output forms, like IDE's and text editors that support links. -- /Jacob Carlborg
Mar 30 2014
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 28.03.2014 19:09, schrieb Walter Bright:
 On 3/28/2014 2:23 AM, monarch_dodra wrote:
 Well, I'm just throwing that out there.

I've thought many times that an error message should be a clickable link. But until console displays support clickable text, it's just a fantasy.

Actually on GNU/Linux systems many do.
Mar 30 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/30/2014 4:04 AM, Paulo Pinto wrote:
 Am 28.03.2014 19:09, schrieb Walter Bright:
 On 3/28/2014 2:23 AM, monarch_dodra wrote:
 Well, I'm just throwing that out there.

I've thought many times that an error message should be a clickable link. But until console displays support clickable text, it's just a fantasy.

Actually on GNU/Linux systems many do.

I just tried it on Ubuntu and - you're right! Pretty awesome. Can the URL be hidden behind text, like you'd do with html: <a href="dconf.org">D Conf!</a> so the user sees the text rather than the link?
Mar 30 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/31/2014 5:10 AM, Steven Schveighoffer wrote:
 We can make this easy:

The trouble with outputting URLs is that they will be significant visual noise to the user. Yeah, I know, another compiler switch :-)
Mar 31 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-03-31 19:02, Walter Bright wrote:

 The trouble with outputting URLs is that they will be significant visual
 noise to the user.

It would be great for those IDE's and text editors that use HTML as output format. -- /Jacob Carlborg
Mar 31 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 I've done this before.

The ecosystem changes (internet, wikis, IDEs, appear), and programmers too change (many learn JavaScript as first language, etc). So what's important is if a feature is good today. Past experience is useful, but only up to a point.
 it's a pain

What is the pain caused by those numbers? Bye, bearophile
Mar 28 2014
prev sibling next sibling parent "Asman01" <jckj33 gmail.com> writes:
On Friday, 28 March 2014 at 11:15:36 UTC, bearophile wrote:
 Walter Bright:

 I've done this before.

The ecosystem changes (internet, wikis, IDEs, appear), and programmers too change (many learn JavaScript as first language, etc). So what's important is if a feature is good today. Past experience is useful, but only up to a point.
 it's a pain

What is the pain caused by those numbers? Bye, bearophile

I think he's speaking about mantain the table with the errors messages and errors code and I did a program that used a similar approach. It was written in C so maping this values is too expansive and tedious. Instead of error("undefined variable %s", id->name); you need to: error(ERR_UNDEF_VAR, get_error_msg_string(ERR_UNDEF_VAR), ERR_UNDEF_VAR, id->name); the error string should contains also error message itself but the formatting too. Formatting are used in functions which do accept a variadic arguments if you do some update in the string and forget to add respective argument or change the order of your enum member and it mismatch to error_msgs_strings table index you just will print garbage/wrong error message and or number/crash program. const char *error_msgs_strings[] = { "error code: %d undefined variable %s", "...", }; Also, I was using linear error codes in this example and you're not looking for this, isn't? I don't know much application which does somethng like this. In this case, a simple error_msgs_strings[ERR_UNDEF_VAR] will not work and you need to create a hashtable. To print a single error code you need to do a search now just like it does for every identifier in the program. It isn't too bad since compile errors aren't too often necessary to do like a search for a identifier in the string table. But it depending how large is your table of error messages and if you are using an approach that isn't exit in the first error message, it will make the edit-and-compile cycle too slow.
Mar 28 2014
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
On Friday, 28 March 2014 at 18:09:00 UTC, Walter Bright wrote:
 On 3/28/2014 2:23 AM, monarch_dodra wrote:
 Well, I'm just throwing that out there.

I've thought many times that an error message should be a clickable link. But until console displays support clickable text, it's just a fantasy.

You could output a URL. Some terminals support magically turning URLs into links.
Mar 28 2014
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
On Sunday, 30 March 2014 at 19:23:43 UTC, Walter Bright wrote:
 On 3/30/2014 4:04 AM, Paulo Pinto wrote:
 Am 28.03.2014 19:09, schrieb Walter Bright:
 On 3/28/2014 2:23 AM, monarch_dodra wrote:
 Well, I'm just throwing that out there.

I've thought many times that an error message should be a clickable link. But until console displays support clickable text, it's just a fantasy.

Actually on GNU/Linux systems many do.

I just tried it on Ubuntu and - you're right! Pretty awesome. Can the URL be hidden behind text, like you'd do with html: <a href="dconf.org">D Conf!</a> so the user sees the text rather than the link?

You can't do that, but you can output the URL and let the terminal figure out that it should make it clickable at least, which is what you just tried.
Mar 30 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 30 Mar 2014 15:23:44 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 3/30/2014 4:04 AM, Paulo Pinto wrote:
 Am 28.03.2014 19:09, schrieb Walter Bright:
 On 3/28/2014 2:23 AM, monarch_dodra wrote:
 Well, I'm just throwing that out there.

I've thought many times that an error message should be a clickable link. But until console displays support clickable text, it's just a fantasy.

Actually on GNU/Linux systems many do.

I just tried it on Ubuntu and - you're right! Pretty awesome.

Yes, I think a url, even if not clickable, is way more useful than an arbitrary error id. It takes not much effort to copy/paste a URL into a browser. We can make this easy: Compiler outputs a URL like this: http://derror.org/2.065/filename.c/l123 Using a function that takes __FILE__ and __LINE__ Then, include a special comment just before the error output that will be parsed by a post-processor, and link that url to the comment (either in github, or on a nice web page). Example: const char *errurl(const char *file = __FILE__, int line = __LINE__); // does this work in C++? I can't remember! // <ERRMSG> A variable cannot be re-defined inside a new scope. See http://dlang.org/... error("is shadowing declaration %s%s", s->toPrettyChars(), errurl()); errurl could be configured to print a URL or nothing via a command line option. Bonus: those who know the error url format know exactly where to go in the code to see where it was printed from. -Steve
Mar 31 2014
prev sibling next sibling parent =?UTF-8?Q?Tobias=20M=C3=BCller?= <troplin bluewin.ch> writes:
Walter Bright <newshound2 digitalmars.com> wrote:
 On 3/28/2014 1:23 AM, Johannes Pfau wrote:
 As an example how this could work, search for CS1002.
 So do we want this?

I've done this before. Short answer, it's a pain and doesn't really help. Searching is easy, just type in the message that was displayed, sans the variable part. I do it all the time.

I think some sort of short identifier for warnings and errors would be beneficial. It does not have to be a number. Advantages not already mentioned: - Messages can change/improve over time, the ID remains the same. - Enable/disable warnings by ID. And this would again enable tools to disable a warning e.g. by right-clicking on the actual message. I imagine there are more similar tasks that can be done with only the ID without actually knowing the meaning of the warning. Like turning warnings into errors if you don't like the usecase of disabling warnings. Since you are already considering URLs in the messages, you need some kind of ID anyway, otherwise you couldn't build an URL. Tobi
Mar 31 2014
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 31 Mar 2014 13:02:48 -0400, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 3/31/2014 5:10 AM, Steven Schveighoffer wrote:
 We can make this easy:

The trouble with outputting URLs is that they will be significant visual noise to the user. Yeah, I know, another compiler switch :-)

Yeah, so? -Steve
Mar 31 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Johannes Pfau:

 How about adding a small 'error-message ID' like DPL00042 to 
 every compiler message? This makes it easier to search for 
 information about the error.

I still think it's a good idea for D. It was proposed time ago. It has two advantages: - Make it easier to find info about an error. The info can explain the bug, show clear examples of the mistake, and how to fix it. - Give some discipline, order and systematicness to the world of D errors/warnings. Bye, bearophile
Mar 28 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2014 2:05 AM, bearophile wrote:
 Johannes Pfau:

 How about adding a small 'error-message ID' like DPL00042 to every compiler
 message? This makes it easier to search for information about the error.

I still think it's a good idea for D. It was proposed time ago. It has two advantages: - Make it easier to find info about an error.

No, it doesn't. Really. Grep does a fantastic job of that.
 - Give some discipline, order and systematicness to the world of D
errors/warnings.

Been there, done that, doesn't work. The ID's also make error messages look just plain ugly, as well as causing premature line wrapping, further uglifying the display.
Mar 28 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-03-28 19:15, Walter Bright wrote:

 The ID's also make error messages look just plain ugly, as well as
 causing premature line wrapping, further uglifying the display.

There can of course be a flag that is required to be used to output the ID of the error message. -- /Jacob Carlborg
Mar 30 2014
prev sibling next sibling parent reply "Andrea Fontana" <nospam example.com> writes:
On Friday, 28 March 2014 at 08:25:05 UTC, Johannes Pfau wrote:
 An idea stolen from C#:

 How about adding a small 'error-message ID' like DPL00042 to 
 every
 compiler message? This makes it easier to search for 
 information about
 the error. If tools want to handle certain compiler errors then
 they can grep for the message-ID instead of the complete 
 message.

 I thought of adding a wiki page, 
 wiki.dlang.org/Compiler_Messages to
 keep a list of all messages. It's then possible to add examples,
 detailed information how to resolve an error and links to 
 further
 information (e.g. changelog entry for error/warning/deprecated 
 message)
 to that page.

 I could file a pull request which does this for all existing 
 error
 messages, but it requires contributors to follow a small 
 protocol
 for future error messages as we need to make sure we do not 
 assign one
 ID to different messages:

 If you want to introduce a new error message:
 Before even opening a pull request,
 * go to  wiki.dlang.org/Compiler_Messages
 * pick next free ID
 * add it to the page with status pending
 * Once stuff is merged update the description/status on the 
 wiki page

 As an example how this could work, search for CS1002.
 So do we want this?

There's another advantage. If you want to change error message (or add localization like in visual c++) you still can found what the error means. It should be easier for IDE to parse and give suggestions or redirect to an help page to solve the problem.
Mar 28 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2014 2:37 AM, Andrea Fontana wrote:
 There's another advantage. If you want to change error message (or add
 localization like in visual c++) you still can found what the error means.

Completely worthless: 1. Programmers program in English. Yes, I've asked many international shops about this. They want error messages in English. 2. The internationalized messages are *terrible* because you need a person who is fluent in that language, and in compilers, to write them. That just doesn't work out too well in practice. 3. Every time you add/change an error message to the compiler, then you have to go back to (2) and try to deal with that. Never works, or you get crappy translations, meaning (1) the foreign programmers again prefer the English messages. I.e. been there, done that. Translated messages are great for a lot of apps, but not for programming tools.
 It should be easier for IDE to parse and give suggestions or redirect to an
help
 page to solve the problem.

The IDE doesn't have to parse them. All it has to do is do a substring search. The IDE developer would have to provide the patterns to search for, but that isn't any harder than creating an indexed table.
Mar 28 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Mar 29 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-03-28 23:33, Kapps wrote:

 But without tool support I feel error codes aren't too useful, and in
 order to provide enough context to make tools useful 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.

We won't get tool support until there are ID's for error message. It's the chicken-and-egg problem. -- /Jacob Carlborg
Mar 30 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/30/2014 4:03 AM, Jacob Carlborg wrote:
 We won't get tool support until there are ID's for error message.

I've pointed out how to do this without ID's several times.
Mar 30 2014
parent Jacob Carlborg <doob me.com> writes:
On 30/03/14 21:16, Walter Bright wrote:

 I've pointed out how to do this without ID's several times.

Are you willing to make the error messages public API? That would go through the same stages of deprecation when they need to change? -- /Jacob Carlborg
Mar 30 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/31/2014 12:47 AM, Andrea Fontana wrote:
 I disagree here.

 1) If you want to google for error, you have to strip extra info (line,
symbols,
 etc)

Copy-paste with a mouse. The same thing you'd do for a message id number.
 2) It happens that you search for an error and you find error from another
 compiler.

I explained to bearophile in this thread how to do site-specific searches with google.
 3) Error messages can be wrong or not well-written (they can contains typos).
If
 you change their description to make them clear you have to change the pattern.
 And if you want to change the format of error messages (let's say: add
 line/column/demangling symbols/giving hints/...) you'll probably brake ide
 parsers. It's quite different if IDE just needs to read the first word of line
 or first match "DPL[0-9]{5}".

Come on, this is not rocket science.
 4) Don't know if this is a case, but two errors can have similar descriptions
 and googling for an error could drive user to the wrong one

Yes, and you can mistype the message number, too.
 5) Why a central map "string code" => "error message" should be harder to
 mantain than a lot of messages putted around the source code?

Because not having a map is easier to maintain than having one.
Mar 31 2014
prev sibling next sibling parent "Joakim" <joakim airpost.net> writes:
On Friday, 28 March 2014 at 09:37:52 UTC, Andrea Fontana wrote:
 There's another advantage. If you want to change error message 
 (or add localization like in visual c++) you still can found 
 what the error means.

This is the only decent reason given for numbering and, considering dmd's not localized yet, is far from being a need. I'm all for putting better explanations of error messages somewhere online, but Walter's right that keyword search is a better interface these days and numbering is unnecessary overhead.
 It should be easier for IDE to parse and give suggestions or 
 redirect to an help page to solve the problem.

If there are such help pages for error messages, there's basically no advantage to numbering over string matching for the error messages and an additional cost of keeping track of all the numbers.
Mar 28 2014
prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Friday, 28 March 2014 at 08:25:05 UTC, Johannes Pfau wrote:
 An idea stolen from C#:

 How about adding a small 'error-message ID' like DPL00042 to 
 every
 compiler message? This makes it easier to search for 
 information about
 the error. If tools want to handle certain compiler errors then
 they can grep for the message-ID instead of the complete 
 message.

 I thought of adding a wiki page, 
 wiki.dlang.org/Compiler_Messages to
 keep a list of all messages. It's then possible to add examples,
 detailed information how to resolve an error and links to 
 further
 information (e.g. changelog entry for error/warning/deprecated 
 message)
 to that page.

 I could file a pull request which does this for all existing 
 error
 messages, but it requires contributors to follow a small 
 protocol
 for future error messages as we need to make sure we do not 
 assign one
 ID to different messages:

 If you want to introduce a new error message:
 Before even opening a pull request,
 * go to  wiki.dlang.org/Compiler_Messages
 * pick next free ID
 * add it to the page with status pending
 * Once stuff is merged update the description/status on the 
 wiki page

 As an example how this could work, search for CS1002.
 So do we want this?

I'm a big fan of CXXXX and LNKXXXX from Visual C++ personally but have never brought it up because I know Walter doesn't care for them. The quality of error messages in D is a weakness in my opinion though so anything to help with that is good in my book. Thinking aloud here, maybe since DMD is switching to D instead of managing IDs they could just be a short hash of the base error message. Then a simple program could scan DMD's source and spot them all and print out a list which could be compared to the wiki list. Something like this: http://dpaste.dzfl.pl/f552c718e935 (which triggers a bug in DMD unfortunately and DMD couldn't use phobos anyway).
Mar 28 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2014 10:28 AM, Brad Anderson wrote:
 I'm a big fan of CXXXX and LNKXXXX from Visual C++ personally but have never
 brought it up because I know Walter doesn't care for them. The quality of error
 messages in D is a weakness in my opinion though so anything to help with that
 is good in my book.

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.) What we have been doing is, when lousy messages are identified, a PR is often produced to improve it. That's how these things get better, one message at a time.
Mar 28 2014
next sibling parent reply Martin Nowak <code dawg.eu> writes:
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.
Mar 28 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/29/2014 11:02 AM, Brad Anderson wrote:
 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

Or you could look up "newline in constant". My point is there's nothing magical about using a number instead. It simply does not enable new features that aren't already there.
Mar 29 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/29/2014 12:07 PM, bearophile wrote:
 Walter Bright:

 On 3/29/2014 11:02 AM, Brad Anderson wrote:
 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

Or you could look up "newline in constant".

If I search this: C2001 newline in constant I see the Microsoft page as first Google result: http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx If I search this: newline in constant The desired Microsoft page is not in the first page of ten results given by Google. The third link it to a not correct page: http://support.microsoft.com/kb/827420

Or you could: visual studio 2013 error newline in constant or: msdn error newline in constant or even better: "newline in constant" site:microsoft.com This is pretty basic google-fu
 (And still, I have not seen addressed the psychological point I have explained
 in a precedent post).

I did, specifically.
Mar 29 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/29/2014 1:11 PM, H. S. Teoh wrote:
 I think there's merit in using an error number. It allows easier
 programmatic processing, for example.

strstr(s,"C2001") is not any easier than: strstr(s, "newline in constant")
 An IDE might want to detect
 certain error numbers and give some more specific user feedback or
 suggest possible fixes.

Sure. But numbers are hardly necessary for that.
 While you *could* do the same with just a string lookup,

And it's trivial to do so. No extra work at all. See strstr() above.
 that's unstable
 because presumably, compiler error messages would be improved every now
 and then, and you don't want a simple rephrasing of the error to require
 updating every single IDE and other tool just to match the new wording
 of the same error.

Sorry, even with numbers, you gotta go fix the strings everywhere. After all, the user would be quite confused if he saw different error messages under "C2001" in the documentation than coming from his compiler. And besides, this DRY problem was solved decades ago. Have a common file from which all message texts are drawn.
 Also, not every error needs a separate number; some parts of the
 compiler may generate different error messages for what is essentially
 the same underlying problem (this may depend on the specific evaluation
 order of the erroneous input, for example). By assigning a single error
 number for both messages, you can aid automated processing tools like
 IDEs to treat a variety of messages as a single logical problem that can
 be uniformly handled.

I suggest a simple solution: if (A || B) { ... common handler code ... }
 To do the same using string lookups will require unnecessary additional
 effort on the part of the IDE/tool implementor. (And it would break as
 soon as a PR that improves compiler error messages gets pulled.)

I've done error numbers before. It is not less effort - it's more - and it's ugly visual noise to the user as well. It's a 1980's solution, forced more or less because memory was incredibly tight and I/O was incredibly slow.
Mar 29 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/29/2014 8:50 PM, Kenji Hara wrote:
 I'll refuse to maintain error number feature.

:-)
Mar 29 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/30/2014 3:53 AM, monarch_dodra wrote:
 I think we should focus on improvements that *really* make a change.

Yup.
Mar 30 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Mar 29 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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?
Mar 29 2014
parent reply Matt Soucy <msoucy csh.rit.edu> writes:
On 03/29/2014 02:53 PM, Walter Bright wrote:
 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?

instantly recognizable, so when users see a DXYZ error code before and remember that they ended up on http://dlang.org/error/DXYZ, they'll be more likely to remember. (I'm looking at you, MSDN pages with impossible-to-remember URLs) This way, the user will eventually just skip the search engine altogether and just go directly to the error's page. -- Matt Soucy http://msoucy.me/
Mar 30 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Matt Soucy"  wrote in message news:lh8nkd$mst$1 digitalmars.com...

 For starters, having a URL such as http://dlang.org/error/D123 is
 instantly recognizable, so when users see a DXYZ error code before and
 remember that they ended up on http://dlang.org/error/DXYZ, they'll be
 more likely to remember. (I'm looking at you, MSDN pages with
 impossible-to-remember URLs) This way, the user will eventually just
 skip the search engine altogether and just go directly to the error's 
 page.

Building a compiler for people who can't google is like building a race track for people who can't drive.
Mar 30 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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
Mar 29 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Friday, 28 March 2014 at 17:28:13 UTC, Brad Anderson wrote:
 Something like this: http://dpaste.dzfl.pl/f552c718e935 (which 
 triggers a bug in DMD unfortunately and DMD couldn't use phobos 
 anyway).

Done at runtime so it works at least: http://dpaste.dzfl.pl/d3aae13a039c
Mar 28 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Friday, 28 March 2014 at 17:28:13 UTC, Brad Anderson wrote:
 (which triggers a bug in DMD unfortunately and DMD couldn't use 
 phobos anyway).

Already reported: https://d.puremagic.com/issues/show_bug.cgi?id=11535
Mar 28 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
On Friday, 28 March 2014 at 18:28:17 UTC, Walter Bright wrote:
 On 3/28/2014 10:28 AM, Brad Anderson wrote:
 I'm a big fan of CXXXX and LNKXXXX from Visual C++ personally 
 but have never
 brought it up because I know Walter doesn't care for them. The 
 quality of error
 messages in D is a weakness in my opinion though so anything 
 to help with that
 is good in my book.

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.
 What we have been doing is, when lousy messages are identified, 
 a PR is often produced to improve it. That's how these things 
 get better, one message at a time.

Yeah, that is true (even if error numbers were adopted). The error message I've always hated the most is "does not match any function template declaration" but error numbers wouldn't help with that one because the error is obvious but what exactly caused it isn't. I kind of wrote out an idea for one way it could be improved awhile back (basically just reformatting the message so you can point an arrow at the failing template constraint). http://forum.dlang.org/thread/mailman.240.1389276481.15871.digitalmars-d puremagic.com?page=4#post-vpglmlxqhiipeyrjfwzx:40forum.dlang.org It's dated though because CyberShadow has since added column numbers and using that would be prefered, I think. Just underlining failing template constraint would do wonders. Combined with colored output and deciphering this error message would be almost pleasant.
Mar 28 2014
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Friday, 28 March 2014 at 18:24:21 UTC, Walter Bright wrote:
 The IDE doesn't have to parse them. All it has to do is do a 
 substring search. The IDE developer would have to provide the 
 patterns to search for, but that isn't any harder than creating 
 an indexed table.

Error messages can and frequently are improved and thus are not usable by tools. Error codes remain constant and thus are usable by tools. IDE support would also allow things like pressing F1 on an error in the error list to be taken to something like wiki/ERR005 which may show an explanation of the error or an example of how to fix it or such. I'm not sure how useful this particular use case is though. In an ideal world errors would be able to be outputted (using a compiler flag) in a program readable way (i.e., JSON or the like, with a code representing the error and data for that particular error, such as { code: ERR003, description: "variable 'foo' is unused", variable: "foo", file: "foo.d", line: 32 }, then your IDE could offer to remove the variable for you immediately, as well as other nice things like that. But without tool support I feel error codes aren't too useful, and in order to provide enough context to make tools useful 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.
Mar 28 2014
prev sibling next sibling parent "w0rp" <devw0rp gmail.com> writes:
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.
Mar 29 2014
prev sibling next sibling parent "froglegs" <nono yahoo.com> writes:
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.
Mar 29 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
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.
Mar 29 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
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.
Mar 29 2014
prev sibling next sibling parent "Brad Anderson" <eco gnuk.net> writes:
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.
Mar 29 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 On 3/29/2014 11:02 AM, Brad Anderson wrote:
 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

Or you could look up "newline in constant".

If I search this: C2001 newline in constant I see the Microsoft page as first Google result: http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx If I search this: newline in constant The desired Microsoft page is not in the first page of ten results given by Google. The third link it to a not correct page: http://support.microsoft.com/kb/827420 (And still, I have not seen addressed the psychological point I have explained in a precedent post). Bye, bearophile
Mar 29 2014
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Mar 29, 2014 at 12:00:51PM -0700, Walter Bright wrote:
 On 3/29/2014 11:02 AM, Brad Anderson wrote:
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

Or you could look up "newline in constant". My point is there's nothing magical about using a number instead. It simply does not enable new features that aren't already there.

I think there's merit in using an error number. It allows easier programmatic processing, for example. An IDE might want to detect certain error numbers and give some more specific user feedback or suggest possible fixes. While you *could* do the same with just a string lookup, that's unstable because presumably, compiler error messages would be improved every now and then, and you don't want a simple rephrasing of the error to require updating every single IDE and other tool just to match the new wording of the same error. Also, not every error needs a separate number; some parts of the compiler may generate different error messages for what is essentially the same underlying problem (this may depend on the specific evaluation order of the erroneous input, for example). By assigning a single error number for both messages, you can aid automated processing tools like IDEs to treat a variety of messages as a single logical problem that can be uniformly handled. To do the same using string lookups will require unnecessary additional effort on the part of the IDE/tool implementor. (And it would break as soon as a PR that improves compiler error messages gets pulled.) T -- VI = Visual Irritation
Mar 29 2014
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 (And still, I have not seen addressed the psychological point 
 I have explained in a precedent post).

I did, specifically.

Sorry, I didn't see it. Bye, bearophile
Mar 29 2014
prev sibling next sibling parent Kenji Hara <k.hara.pg gmail.com> writes:
--001a1134d6164ef08a04f5cad450
Content-Type: text/plain; charset=UTF-8

I agree with Walter here. Maintaining error numbers for all errors would
require not little cost for compiler code and documentations, AND it will
slow down compiler improvements for more better diagnostic messages so we
would need to keep backward compatibility of error numbers.

I'll refuse to maintain error number feature.

Kenji Hara

2014-03-30 5:11 GMT+09:00 H. S. Teoh <hsteoh quickfur.ath.cx>:

 On Sat, Mar 29, 2014 at 12:00:51PM -0700, Walter Bright wrote:
 On 3/29/2014 11:02 AM, Brad Anderson wrote:
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

Or you could look up "newline in constant". My point is there's nothing magical about using a number instead. It simply does not enable new features that aren't already there.

I think there's merit in using an error number. It allows easier programmatic processing, for example. An IDE might want to detect certain error numbers and give some more specific user feedback or suggest possible fixes. While you *could* do the same with just a string lookup, that's unstable because presumably, compiler error messages would be improved every now and then, and you don't want a simple rephrasing of the error to require updating every single IDE and other tool just to match the new wording of the same error. Also, not every error needs a separate number; some parts of the compiler may generate different error messages for what is essentially the same underlying problem (this may depend on the specific evaluation order of the erroneous input, for example). By assigning a single error number for both messages, you can aid automated processing tools like IDEs to treat a variety of messages as a single logical problem that can be uniformly handled. To do the same using string lookups will require unnecessary additional effort on the part of the IDE/tool implementor. (And it would break as soon as a PR that improves compiler error messages gets pulled.) T -- VI = Visual Irritation

--001a1134d6164ef08a04f5cad450 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I agree with Walter here. Maintaining error numbers for al= l errors would require not little cost for compiler code and documentations= , AND it will slow down compiler improvements for more better diagnostic me= ssages so we would need to keep backward compatibility of error numbers.<di= v> <br></div><div>I&#39;ll refuse to maintain error number feature.<br><div cl= ass=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Kenji Hara<br><br>= <div class=3D"gmail_quote">2014-03-30 5:11 GMT+09:00 H. S. Teoh <span dir= =3D"ltr">&lt;<a href=3D"mailto:hsteoh quickfur.ath.cx" target=3D"_blank">hs= teoh quickfur.ath.cx</a>&gt;</span>:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= adding-left:1ex"><div class=3D""><div class=3D"h5">On Sat, Mar 29, 2014 at = 12:00:51PM -0700, Walter Bright wrote:<br> &gt; On 3/29/2014 11:02 AM, Brad Anderson wrote:<br> &gt; &gt;For example, in VC++ if you get &quot;C2001 newline in constant&qu= ot; you<br> &gt; &gt;can just lookup C2001<br> &gt; &gt;<a href=3D"http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx" = target=3D"_blank">http://msdn.microsoft.com/en-us/library/4x3c2e37.aspx</a>= <br> &gt;<br> &gt; Or you could look up &quot;newline in constant&quot;.<br> &gt;<br> &gt; My point is there&#39;s nothing magical about using a number instead. = It<br> &gt; simply does not enable new features that aren&#39;t already there.<br> <br> </div></div>I think there&#39;s merit in using an error number. It allows e= asier<br> programmatic processing, for example. An IDE might want to detect<br> certain error numbers and give some more specific user feedback or<br> suggest possible fixes.<br> <br> While you *could* do the same with just a string lookup, that&#39;s unstabl= e<br> because presumably, compiler error messages would be improved every now<br> and then, and you don&#39;t want a simple rephrasing of the error to requir= e<br> updating every single IDE and other tool just to match the new wording<br> of the same error.<br> <br> Also, not every error needs a separate number; some parts of the<br> compiler may generate different error messages for what is essentially<br> the same underlying problem (this may depend on the specific evaluation<br> order of the erroneous input, for example). By assigning a single error<br> number for both messages, you can aid automated processing tools like<br> IDEs to treat a variety of messages as a single logical problem that can<br=

<br> To do the same using string lookups will require unnecessary additional<br> effort on the part of the IDE/tool implementor. (And it would break as<br> soon as a PR that improves compiler error messages gets pulled.)<br> <span class=3D""><font color=3D"#888888"><br> <br> T<br> <br> --<br> VI =3D Visual Irritation<br> </font></span></blockquote></div><br></div></div></div> --001a1134d6164ef08a04f5cad450--
Mar 29 2014
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Sunday, 30 March 2014 at 05:12:35 UTC, Walter Bright wrote:
 On 3/29/2014 8:50 PM, Kenji Hara wrote:
 I'll refuse to maintain error number feature.

:-)

Well, I think would be a "nice plus". If we have it, "yay!", but if we don't, I won't miss it. Given Walter and Kenji's (and the rest of DMD's) limited manpower, I completely support their decision to not deploy this. I think we should focus on improvements that *really* make a change.
Mar 30 2014
prev sibling next sibling parent =?UTF-8?B?Ik5vcmRsw7Z3Ig==?= <per.nordlow gmail.com> writes:
 I think we should focus on improvements that *really* make a 
 change.

I've been missing from time to time the ability to sort my messages on *type* rather than file or line together with an IDE that present these in a tree (GUI) view where each warning message type node can be expanded or compressed. At least for big projects written in C/C++ where people have accidentally turned off important warning messages and then some other guy have found out that we need to turn it on (again) this would be a useful feature. This mainly because it's easier to fix a set of similar warnings at the same time as the solutions often are more closely related than warnings of different kind related solely by line locality. Now, of course, D isn't C/C++ and D programs don't generated as my garbage output as C/C++ does when compiled...but still could become handy in very large D projects.
Mar 30 2014
prev sibling parent "Andrea Fontana" <nospam example.com> writes:
On Friday, 28 March 2014 at 18:24:21 UTC, Walter Bright wrote:
 On 3/28/2014 2:37 AM, Andrea Fontana wrote:
 There's another advantage. If you want to change error message 
 (or add
 localization like in visual c++) you still can found what the 
 error means.

Completely worthless: 1. Programmers program in English. Yes, I've asked many international shops about this. They want error messages in English.

Good to know. I don't like l10n of messages but many app simply use os default language. I hope it doesn't happen then.
 2. The internationalized messages are *terrible* because you 
 need a person who is fluent in that language, and in compilers, 
 to write them. That just doesn't work out too well in practice.
 3. Every time you add/change an error message to the compiler, 
 then you have to go back to (2) and try to deal with that. 
 Never works, or you get crappy translations, meaning (1) the 
 foreign programmers again prefer the English messages.
 I.e. been there, done that. Translated messages are great for a 
 lot of apps, but not for programming tools.

I agree with you about english and programming. My point was to show you that there are cases where error codes are useful. (however it's not that difficult to translate a message in your own native language)
 It should be easier for IDE to parse and give suggestions or 
 redirect to an help
 page to solve the problem.

The IDE doesn't have to parse them. All it has to do is do a substring search. The IDE developer would have to provide the patterns to search for, but that isn't any harder than creating an indexed table.

I disagree here. 1) If you want to google for error, you have to strip extra info (line, symbols, etc) 2) It happens that you search for an error and you find error from another compiler. 3) Error messages can be wrong or not well-written (they can contains typos). If you change their description to make them clear you have to change the pattern. And if you want to change the format of error messages (let's say: add line/column/demangling symbols/giving hints/...) you'll probably brake ide parsers. It's quite different if IDE just needs to read the first word of line or first match "DPL[0-9]{5}". 4) Don't know if this is a case, but two errors can have similar descriptions and googling for an error could drive user to the wrong one 5) Why a central map "string code" => "error message" should be harder to mantain than a lot of messages putted around the source code?
Mar 31 2014