The second problem I have with the error texts is their lack of
structure. Since the error messages are much more verbose, there is
now a need to have some short form that follows conventions for
various tools. For example:
* There's a whole range of tools that work with the usual
"file:line:vol: message" per line format -- Emacs compilation
buffer, the on-line-check-syntax-like error highlighting, log
parsers, etc. (The emacs on-line checking is something that two
people already noticed as a victim...)
* In xrepl, what I did was show just the error message and omitted
the stacktrace. The idea is that the stacktrace is usually
useless, so make it available but omit the default display. This
is no longer possible (especially with what I talked about in the
other thread: showing just the first line results in useless
error messages).
* There are two contexts where error messages are unwieldy: TR and
contract errors. In both of these the error text is huge to the
point of making a useless text that you need to manually grep
through. In TR it got bad enough that Vincent put some serious
effort in making them shorter, and with contracts the problem is
still there (though not as bad as TR was). This was something
that we talked about at some point -- consider a very likely
mistake:
(plot sin)
This results in more than 80 lines of an error message, getting
the "TR effect" where in drracket you're now staring at the
bottom of that goop and have no clue what to make of it. (Worse
if that wasn't the first interaction -- since you can't also go to
the top, you need to slowly scroll up and look for the beginning
of the error).
The sub-field printout could have helped here, but again since
there's no structure it's impossible to do.
There are two problem here. First, there's the lack of structure,
since the messages are just plain text. A possible way to address
this is with a precise specification for the format, and then writing
an interface that pretends that there are fields. This will probably
require some changes to the interface, like the kind of text that you
can use in `raise-arguments-error' fields, and detection of newlines
in the values. It might also require fixing the inconsistencies that
are common now.
The second problem is worse -- without a specified meaning for the
fields, there is no way to reliably construct such one-liners. It's
worse because a specification for the meaning of known fields will be
hard to design and harder to enforce.
--
((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
