On the subject of error messages

[Steven Schveighoffer via Digitalmars-d]

On 5/16/17 2:29 PM, Stanislav Blinov wrote:
> On Tuesday, 16 May 2017 at 15:47:37 UTC, Steven Schveighoffer wrote:
>> On 5/16/17 9:54 AM, Stanislav Blinov wrote:
>>> On Tuesday, 16 May 2017 at 12:27:30 UTC, Steven Schveighoffer wrote:

>> When I have a type like this:
>>
>> struct S
>> {
>>    int foo;
>> }
>>
>> and the hand-written error message says: "Your type must be a struct
>> that contains an integer property named 'foo'". How does that help me
>> figure out what I did wrong? We can spend all day arguing over how
>> nice this message is, but the truth is, what the constraint writer put
>> in the constraints, and how the compiler is interpreting it, may be 2
>> different things. This helps nobody.
>
> It cannot be that way. Whoever wrote the constraint possesses knowledge
> about it's semantics. If they put wrong message there, then that's a
> bug, or they're a... well, not a very good person.

This is the only time I have issues. Most of the time, the constraint is 
straightforwardly simple and the problem is obvious just by looking at 
the constraint and the type.  When that's not the case, figuring out why 
the constraint doesn't seem to be doing what it says it's doing is the 
hard part.

This can be achieved any number of ways. The most straightforward and 
effective way is to have the compiler simply expose what it's doing.

>>> That is why (static) asserts have an optional string argument: to
>>> display a clean an readable error message, instead of just dumping some
>>> code on the user. The same thing, in my opinion, is needed for
>>> constraints.
>>
>> If assert(x == 5) would just print "Error: x == 4" automatically, we
>> could eliminate most needs for a message.
>
> You're taking overly simplified pieces of code and base your reasoning
> on them, while you know full well it's almost never this simple.
>
> assert(x.veryBadlyNamedFunction == obscureStateObtainedFromElsewhere);
>
> "Error: x.veryBadlyNamedFunction == 42"
>
> Very helpful message.

Not here to debate this "feature", but if it says what the return value 
was, and the name of the symbol it's checking against (and its value), 
then yes, combined with the usual stack trace it's incredibly useful. 
Most of the time, that's what I would normally write in the message, but 
that in itself isn't easy to do.

>> You could solve this with a message, but again, this is a huge task to
>> undertake on ALL code in existence, rather than fixing
>
> I seem to be expressing myself poorly, as I find I must repeat it the
> second time already: I never suggested to change any existing code. I
> suggested an *optional* mechanism of reporting errors.

No, I mean having the optional mechanism fixes nothing. Someone then has 
to go through all existing code and determine what the existing 
constraints are testing for, and then determine the best way to write 
the messages. That's not a trivial amount of work.

>> it all to a "good enough" degree that we don't need the messages. And
>> it avoids the "human compiler" that is prone to error.
>
> This again. No it does not. If there's a bug in the constraint, there is
> a bug in the constraint. Messages or no, it's all the same. Either it
> does what it's supposed to do, or it doesn't. Reporting the wrong
> message is a bug, as is returning false for compliant type, or true for
> malicious one.

There could be no bug in the constraint, but the message is misleading, 
wrong, or easy to misinterpret. It's adding another layer of potential 
issues.

-Steve