On Fri, Dec 10, 2010 at 10:38 AM, Robby Findler <ro...@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 <e...@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! >> > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev