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! _________________________ Racket Developers list: http://lists.racket-lang.org/dev