Quality of errors in DMD

Shachar Shemesh via Digitalmars-d digitalmars-d at puremagic.com
Sun Sep 4 07:19:35 PDT 2016


On 04/09/16 01:39, Walter Bright wrote:
> On 9/3/2016 6:14 AM, Jacob Carlborg wrote:
>> What kind of issue due you see with trying to print some form of
>> information
>> when an assertion fails?
>
> Because it's useless to anyone but the compiler devs, and it adds cruft
> to the compiler. And even worse than useless, it confuses the user into
> thinking it is a meaningful message.

assert(0, "Compiler bug: symbol table should have been initialized by 
this point");

This confuses the user less than the current situation, and at the same 
time give people who are genuinely trying to have the compiler something 
to work on to understand why the assert is there.

Speaking for my own, the RAID team in Weka started a rule saying not to 
allow asserts with no strings in our code. Every assert should have a 
message, preferably with parameters, giving some hint regarding what 
went wrong and what the expected values should have been. It's a pain to 
write them, but it more than pays off when they get actually triggered.

We just found out that having just the assert, even when the condition 
makes it clear, even when there is a comment next to it explaining it, 
is just too confusing. More often than you think, it also involves 
cursing yourself for not having the value of one variable or another 
(and, no, the cores are, more often than not, useless. I'm not sure why).

I understand you don't see the need, but I'd like you to consider the 
possibility that having more people able to hack the front end is also 
something that would help to give D a boost. If the cost of becoming a 
compiler developer was lower, wouldn't things progress more rapidly?

Shachar


More information about the Digitalmars-d mailing list