Jack Repenning <jrepenning@collab.net> writes:
> I think the difference between wanting outermost first or last, is the
> difference between
> svn failingcommand
> and
> svn failingcommand 2>&1 | more
>
> That is: some common use patterns give easiest access to the first
> lines, others to the last lines. No help there.
I think there *is* a reason to prefer outermost last, in this context.
The audience for these stacks is users, who generally expect that if
the program has something to tell them, it will say it as near to
their returning prompt as possible -- because otherwise, the message
might get lost in the scrollback.
In Subversion, as we move outward in an error stack, we move closer
and closer to something that's comprehensible to the user, e.g.,
libsvn_fs/dag.c: error: fs graph acyclitude not maintained
||
||
\/
libsvn_repos/blah.c: error copying directory
||
||
\/
[....]
||
||
\/
copy-cmd.c: error: commit failed
So the main point is made excruciatingly clear: your commit failed.
Then you can scroll back to see why (or just cut and paste it into a
mail to the dev list.)
But currently, we print them in the opposite order, and even though I
am very accustomed to GDB stack traces in that order(!!), I still get
confused every time by Subversion's error stacks.
> I can tell you that Python stacks (outermost first) drive me buggers,
> because I'm so used to Java stacks (outermost last). But Java stacks
> used to drive me nuts because they were inverted from adb stacks. Go
> figure. I don't think there's any compelling argument to be had, here.
When it comes to a debugger printing out a stack trace, I agree
there's no compelling reason to prefer one way over the other. But
error stacks being presented to the user are different...
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 21 22:42:02 2003