You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by kf...@collab.net on 2003/07/21 18:53:22 UTC
propose to print error stack in unreversed order
kfogel@tigris.org writes:
> New Revision: 6524
> Log:
> Fix issue #1384: If 'svn mkdir' errors because the target already
> exists, then have it suggest 'svn add' as an alternative.
>
> * subversion/clients/cmdline/mkdir-cmd.c
> (svn_cl__mkdir): Wrap error from svn_client_mkdir, if EEXIST.
With this commit, the user now sees:
$ subversion/clients/cmdline/svn mkdir already-existing-target
subversion/clients/cmdline/mkdir-cmd.c:72: (apr_err=17)
svn: File exists
svn: Try 'svn add' or 'svn add --non-recursive' instead?
subversion/libsvn_subr/io.c:1501: (apr_err=17)
svn: can't create directory 'already-existing-target'
$
This is more helpful than before, but it would be even better in this
order:
$ subversion/clients/cmdline/svn mkdir already-existing-target
subversion/clients/cmdline/mkdir-cmd.c:72: (apr_err=17)
subversion/libsvn_subr/io.c:1501: (apr_err=17)
svn: can't create directory 'already-existing-target'
svn: File exists
svn: Try 'svn add' or 'svn add --non-recursive' instead?
$
In fact, as I thought about it, I couldn't come up with a case where
one wouldn't want the outermost error printed last. That would also
match the intuitive order of things: first X went wrong, which caused
Y, which finally resulted in our printing Z, where Z is "commit
failed" or "update failed" or "try this other command" or whatever.
How would people feel if error.c:handle_error() printed errors out in
that order? I think it would improve our error messages a lot.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: propose to print error stack in unreversed order
Posted by Brian Denny <br...@briandenny.net>.
>
> 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.
FWIW, I agree w/Karl.
-brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: propose to print error stack in unreversed order
Posted by kf...@collab.net.
Jack Repenning <jr...@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
Re: propose to print error stack in unreversed order
Posted by Jack Repenning <jr...@collab.net>.
At 1:53 PM -0500 7/21/03, kfogel@collab.net wrote:
>In fact, as I thought about it, I couldn't come up with a case where
>one wouldn't want the outermost error printed last.
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 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.
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org