[racket-dev] Error message proposal

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'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!