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.
