[racket-dev] Error message proposal

On Thu, Jun 21, 2012 at 4:21 AM, Eli Barzilay <eli at barzilay.org> wrote:
> Three hours ago, Matthew Flatt wrote:
>> I think you're asking for two changes to the error-message syntax:
>>
>>  * Move srcloc back to the front of error messages.
>>
>>  * Support multi-line messages: the first line is supposed to be
>>    useful on its own, but extra lines act as a kind of detail field
>>    that is nicely placed and particularly prominent.
>
> Yes, but I thought that the second is already there by the fact that
> multiple lines are now the norm.  IOW, I assumed that it is now fine
> to do something like
>
>  (error 'foo "blah blah\n  blah: blah\n")
>
>
>> As long as the extra lines are indented by one space to make them
>> easily parseable, those changes sound fine to me.
>
> Yes (except I use two spaces in texts too...), and since we're parsing
> texts, there's a problem with the line having a colon in it.
>
> There's a bunch of options for that, like an empty line, or forcing
> all fields to have their values on the next line and doubly-indented.
>
> (I'd much rather prefer to have the structure in the data, but I
> remember the problems with that.  Maybe have a wrapper for primitive
> exceptions that does the parsing?  OTOH, the nice thing about strings
> is that it's easily compatibil with existing multi-line error
> messages.)
>
> So given that it's one paragraph -- I think that the easiest solution
> is one line, and have the error display handler do the text wrapping.
>
>
>> Your example message contains a sentence with capitalization and an
>> ending period. As nice as it looks in the example, that kind of text
>> composes badly, so I'd prefer to stick with lowercase and (as needed)
>> semi-colons.
>
> I was thinking in the direction of catering for the longish
> explanations that Ryan was suggesting, and the suggestions in the
> linking error messages, etc.  Semicolons would probably also
> discourage longer messages.  Finally, if that text is shown in a popup
> or shown separately in xrepl, it would look odd.
>
> Anyway, I'm thinking that the main thing should be a separation
> between the information (= the text) and the rendering.  So how about
> this: leave capitals+dots and do the obvious regexp-replacing
> (together with the wrapping, given the above) in the default display
> handler?

I think Matthew is concerned with the code that constructs the error
messages and being able to build strings from parts coming from
different places..

>> I'm also happy to allow the initial name in an error messages to be
>> sometimes an entity that is complained about, instead of always the
>> complaining entity. (That's not in the message below, except by
>> indirection.)
>
> I'm not following that last comment.
>
>
>> Meanwhile, I think you're asking for some changes to existing error
>> messages, such as adapting some existing messages that can be
>> usefully broken into first and second lines. I have certain specific
>> hanges in mind; probably we'll have to take them one-by-one at some
>> point.
>
> OK.  (I'll be very happy to do whatever.)
>
>
>> Finally, I think you're asking for a change to DrRacket:
>>
>>  * Don't show any fields beyond the first line until the user clicks
>>    somewhere.
>>
>> That doesn't sound practical to me. When I call a function with the
>> wrong number of arguments, for example, I don't want to have to click
>> to find out how many arguments are expected.
>
> That "beyond the first line" was a little extreme -- I'm thinking
> about having the long-second-line thing showing all of the really
> necessary details, and then the fields showing complete details.
>
>
>> I think it will work better to have a field convention or syntax to
>> indicate whether a field should be hidden by default. How about
>> using "..." at the end of a field name to indicate that it could be
>> hidden by default?  [...]
>
> To translate the errors you've written (as would be shown by the
> default display handler, when showing all fields too):
>
>  > (+ 1 'a)
>  +: contract violation
>    `+' expected a number in its 2nd argument; given 'a
>    expected: number?
>    given: 'a
>    argument position: 2
>    other arguments:
>      1
>    context:
>      [...]
>  > (add1 1 2 3)
>  add1: arity mismatch
>    `add1' does not expect 3 arguments
>    expected number of arguments: 1
>    given number of arguments: 3
>    arguments:
>      1
>      2
>      3
>    technical note: this is a contract violation for the application
>      form
>    context:
>      [...]
>
> But if you want some markup, then another thing to consider is some
> way to allow customizing these things -- for example, maybe some error
> has two fields that are the same only one is more detailed (eg, a
> short path in one, and absolute one in the other).  Or maybe you want
> to see some particular bit that most people don't.
>
> (These are not issues that are specific to the overall suggestion
> though.)
>
> --
>          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                    http://barzilay.org/                   Maze is Life!
> _________________________
>  Racket Developers list:
>  http://lists.racket-lang.org/dev