[racket-dev] [plt] Push #21701: master branch updated

On Fri, Dec 10, 2010 at 10:38 AM, Robby Findler
<robby at eecs.northwestern.edu> wrote:
> Both this and Sam's idea seem like good ways to improve the error
> message to me. Not sure if Casey or Sam (or Christos?) wants to try to
> their hand at the actual formatting or not. I will, if not.
>
> I don't like the "possible fixes include" language, tho-- I prefer
> that we either say that this error message is a result of these two
> places being wrong and thus fixing one of them will make it go away or
> we don't say that.

uhh.. "don't say anything", I meant to write.

Robby

> I lean towards including it because I think that feedback along the
> lines of "hey! this error message is wrong because I had to fix a
> third place" will help us make the contract system better, but perhaps
> Casey's feedback is already enough to make us drop it, I'm not sure.
>
> Robby
>
> On Fri, Dec 10, 2010 at 10:22 AM, Eli Barzilay <eli at barzilay.org> wrote:
>> Three hours ago, Robby Findler wrote:
>>> Okay. So I'll just start by spelling out the pieces of information
>>> that's there to be put into a message:
>>>
>>>  - is the contract blaming the party where the contract was written (or not)
>>>  - the source location where the contract was written down
>>>  - the contract, written out
>>>  - the names of the two parties
>>>  - a violation specific message with some details (ususally of the
>>>    form "expected an <integer?>, got #f" or similar)
>>>
>>> The current error message uses that first thing as a conditional and
>>> has a different sentence for each of those cases.
>>
>> [Warning: see my earlier claim of being inexperienced, so use lots of
>> salt.]
>>
>> I think that "a sentence" is where the mistake starts -- it works for
>> short error messages (that are almost always on one line), but the
>> long contract error messages is what makes it annoying to me --
>> especially when there's so many bits there, which means that you
>> need more verbiage and the result is even less clear (I read it like a
>> story to myself, pointing at an imaginary side where my code and
>> another side where the other code is...).
>>
>> How about this:
>>
>>  client contract violation: <viloation message>
>>    at:       <name/source of client>
>>    contract: <contract>
>>    library:  <name/source of library>
>>    (contract from: <contract source>)
>>
>> and
>>
>>  library self-contract violation: <viloation message>
>>    library:  <name/source of library>
>>    contract: <contract>
>>    caller:   <name/source of client>
>>    (contract from: <contract source>)
>>
>>
>> The words don't matter much, but the idea is:
>>
>>  * Show the error message first, that's the most important thing for
>>    me, for some cases like "expected an <integer?>, got #f" I'd
>>    probably know immediately where the problem is.
>>
>>  * Show the faulty code next -- for almost all errors this in
>>    combination to the above is all I need to know.
>>
>>  * Show the contract next, in more complex cases (like when I
>>    confused arguments and have multiple errors, I'll try to decipher
>>    this).
>>
>>  * Show the library source, just in case there's some problem there
>>    (eg, I need to complain or make a feature request, or I'm the
>>    library author and I'm trying it).
>>
>>  * And finally show the contract location (the least required bit of
>>    information for the error).
>>
>> In addition, I made the message part appear first assuming that it's
>> usually small, and read as text.  The following bits of information
>> are all aligned to make them stick out nicely, and I expect that it
>> won't take me long before my eyes would learn to quickly jump to the
>> relevant information -- this also assumes that each of the bits take
>> one line.  The last one is not aligned, but it's aplpicable in cases
>> rare enough to not matter.  I don't think that there's any further
>> need for explanations (like "the error might be here, or there, or
>> there") -- I see where the contract is defined, and in the rare cases
>> where none of the lines make sense, I'll get there naturally to find
>> out how the bogus contract is defined.
>>
>> It's very important (IMO) that the lines are short, for example
>>
>>  at: /Users/clklein/tmp/contract-violator.rkt:9.17: (file /Users/clklein/tmp/contract-violator.rkt)
>>
>> is bad since it will almost always wrap[*].  I prefer lots of
>> shorthands, like "<collects>/foo/bar.rkt" or
>> "<home>/tmp/contract-violator.rkt", as well as dropping out obvious
>> pieces: in the above case there's no need for the (file ...) part; in
>> a library require there's no need for the path.
>>
>>
>>
>> [*] (Except for Kevin, who will laugh at the attempt to go beyond a
>>    1/4 of his screen's width...)
>> [*] (And except for Sam, who is blind to soft line breaks...)
>> [*] (Perhaps except for {everyone, except for people who like to use
>>    really big fonts}.)
>>
>> --
>>          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>>                    http://barzilay.org/                   Maze is Life!
>>
>