On Thu, Jun 21, 2012 at 4:21 AM, Eli Barzilay <[email protected]> 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 _________________________ Racket Developers list: http://lists.racket-lang.org/dev
