[Grok-dev] three ways to do error messages

[Brandon Craig Rhodes]

I started a branch to start making Grok error messages more friendly
and less traceback-crazed, and realized that there are at least three
approaches we could take.  Maybe more.  I'll outline them; please
weigh in on which way we should take, I'm eager to get started:

 1. Where we today raise GrokError, we could call a function that
    prints the message, and then does something like a sys.exit(1) to
    avoid a traceback.

 2. We could raise an error that martian recognizes and then martian
    could take responsibility for printing it and doing the
    sys.exit(1).  Since all of the GrokErrors I've seen so far are
    ones for which a traceback is useless - and, after all, if the
    error occurs during grokking, then by definition hasn't the code
    that caused the error already been run? - maybe GrokError could
    become the one that doesn't bother with an exception, and we could
    invent a GrokErrorWithException or something to cover any corner
    cases we found where one is needed.

 3. Maybe the grokkers should all be run, catching GrokErrors along
    the way, and then they should all print at once, so if you've
    forgotten three templates you get told all at the same time
    instead of fixing one problem, re-running Grok, etc?  I would be
    against this if Grok errors turn out to be the sort that cascade,
    creating the horrible "cc" situation where you get buried with
    consequences of some single, initial error that's way way up at
    the top of the output.  But my impression so far is that they're
    pretty atomic - that they don't tend to "cause" each other.

Plus, there's the whole other issue - which might need work on Zope
itself - that SyntaxErrors raised during testing never show me the
dratted line of code that I've messed up, but instead just show me the
line number and a completely useless traceback into some horrible ZCML
code or something.  Should we try fixing this too?  I'm not as
concerned with the testing story as with general development at the
moment, though.

-- 
Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon