Numbering compiler error messages?

Asman01 jckj33 at gmail.com
Fri Mar 28 08:15:57 PDT 2014


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.


More information about the Digitalmars-d mailing list