[racket-dev] Error message structure (error-message overhaul)

Earlier today, Neil Toronto wrote:
> On 06/19/2012 06:11 PM, Eli Barzilay wrote:
> > [...]
> >        (plot sin)
> > [...]
> 
> Hear, hear! I make this mistake myself after going a month or two
> without plotting anything.

(Off-topic for the thread, but why not make that work since it's
apparently an even more popular expectation than I thought if *you*
make that mistake?)


> Every time, I've dreaded some possible future in which I do it in
> front of a non-Racketeer.

Yeah -- and with students this "dread" is translated to concrete
terms: when a student sees such an error message (TR, in my case),
they will, in the absolute majority of cases, complain that my code is
broken.  I've had plenty of semesters that were free of any problems
in my course code, yet when students saw these errors they'd quickly
conclude that my code is broken.


12 hours ago, Robby Findler wrote:
> I don't know if it is intended, but these messages come across as
> just disliking the idea of putting more (and structured) information
> into the error messages.  I'm guessing Eli does not intend that [...]

Your guess is very much correct.  I very strongly *like* the idea of
both more information and of more structure.  In fact, the
`plot'-error is something that we talked about at NEU shortly before
Matthew did this revision, and one of the things that we rolled around
was having a similar kind of structure.  And only a week later when
Matthew came I learned about the revision that does it half-way in a
text format.  So on the structure side, I'd really like to have *more*
of it.

On the information side, one of the disadvantages of having just text
is that you can't add more random bits of information since soon enogh
all error messages become multi-page disasters -- so it's implicit in
my other discussion on the organization of errors, but another goal
that I would very much like to promote is to have *more* information
(and make it possible by not always showing all of it).


> And while I'm certainly biased, I don't dread showing the (plot sin)
> message to a Racket outsider. I think it is pretty informative, if
> you start at the beginning and read it out loud.

It might look like a joke if I'll quote how a student would read it,
but it's more than just a joke -- it's an explanation for why they
don't have a clue about what went wrong, then resort to this verbatim
reading, and later the inevitable conclusion that "the software is
broke".


> Anyways, I can see two possibilities to help here. See if either of
> them seem reasonable to those unsatisfied:
> 
> 1) we can adjust pretty-print so it (when it fits), puts lists that
> have keywords followed by non-keywords on the same line. [...]

That would be a good tweak, but I don't think that it's enough to
avoid the reaction I'm talking about...


> 2) in DrRacket, we can adjust the error print handler so that it
> prints only the first three or four lines (or perhaps the first two
> sections or something like that) and then puts a "more ..." link (in a
> different font in a nice looking way like we see all over the web)
> that will unfold the entire error.

That's very close to a concrete suggestion that I started on last
night.  I'll post that in another thread.


20 minutes ago, Neil Van Dyke wrote:
> 
> FWIW, I think I can make the Emacs stuff work better with the new
> error message format.

Only if it becomes reliabley parsable.  But in any case, what I talked
about is the fact that there are many tools that "just work" with the
traditional error messages.


> On a related matter, it's helpful when file names in error messages
> contain a complete path.  (Prior to these new error messages, for
> example, "raco setup" would produce a mix of relative and absolute
> paths in error messages.)

That's related to this because if there are known "properties" with
specific kinds of values, then the decision to show a shortened name
can be done in the renderrer.


> Performance-wise, for exceptions involving paths, if resolving a 
> complete path happens to be expensive...

(One of the nice things about errors is that performance is usually
not an issue...)

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!