Add option to print backstrace in reverse order(stack frames first & error last)
Currently the way ruby prints the backtrace is that the error comes first & then the stack frames. like this
Main Error Message stack frame 1 stack frame 2 stack frame 3 .....
this is perfectly fine provided
- Backstraces are short, so fits in terminal.hence, no need to scroll.
- you read it from top to bottom.
But, I am a rails developer where
- Backstraces are always HUGE, therefore seldom don't fit in terminal. Means LOTS of scrolling to do everytime we get an error.
- in terminal we tend to read backstraces from bottom to top, especially when tailing(tail -f) the production logs.
- people, who practice Test-driven development literally spend most of their time scrolling to read backstraces to the point most end up buying a larger display.
Please add a way so we can configure backstraces to be printed in reverse order. so if you are reading from bottom, say from terminal, you can get the main error message without need to scroll. like this
stack frame 3 stack frame 2 stack frame 1 Main Error Message .....
this would save lot of time because when the error message is print at the bottom, no need to scroll for reading it. Not sure if this can be done today. I tried Overriding Exception#backtrace but it caused stack level too deep & illegal hardware instruction Error.
Attached are currently what backstrace currently looks like & how there be an option to make it look for comparison.
Updated by nofxx (Marcos Piccinini) over 3 years ago
Already doing the rescue & reverse, but need to do it on every project...
Another use case is when using some monitor (e.g. guard) to run tests as you code:
When there's a fail one needs to switch to terminal and scroll up to see the lines that matter.
Updated by nobu (Nobuyoshi Nakada) about 3 years ago
- Status changed from Open to Closed
Applied in changeset ruby-trunk:r57685.
eval_error.c: backstrace in reverse order
- eval_error.c (rb_threadptr_error_print): print backtrace and error message in reverse order if STDERR is unchanged and a tty. [Feature #8661]
Updated by Eregon (Benoit Daloze) almost 3 years ago
Should matz give an opinion on this feature?
It's a pretty big change for the user, I got confused a couple times by it when running trunk.
Particularly, if a test framework prints a backtrace in the old order, but then some exception kills the test framework then there is a mix of backtrace in old and new order.
I see from the commit this is limited to top-level backtraces printed to stderr.
This is good to limit breaking compatibility but also inconsistent with the Exception#backtrace order for instance.
Even then, it might already break compatibility significantly if anyone depends on the output of the top-level exception handler.
Also, I am not sure this addresses the OP concern, since the display of the backtrace in Rails is rarely an exception going to the top-level (which would be affected by this change) but managed by some handler printing the exception in the log (managed by Rails and can only be changed there).
In any case, if this remains for 2.5 it should be mentioned in the NEWS file.
Updated by naruse (Yui NARUSE) almost 3 years ago
We expect some people may object this.
Therefore we're gathering feedback now (so thank you for your feedback).
To gather feedback wider, we'll give final decision after preview 1, including rspec and Rails will follow this change or not.
In any case, if this remains for 2.5 it should be mentioned in the NEWS file.
Yeah, NEWS should include this and note as EXPERIMENTAL.
I add it.
Updated by shyouhei (Shyouhei Urabe) almost 3 years ago
FYI it is intentional for this feature being automatically enabled right now, instead of some configuration like the OP requests.
The reason behind this is that stderr is expected to be passed to other processes (like some logging infrastructure for instance). If the order of backtraces is configurable, it becoms impossible for such outer-process things to detect which. So configuration is a bad idea in this area. Either the backtrace is ascending or descending, that order should be static and should never be configurable.
P.S. I get confused too so I personally don't like the way it is.
Updated by kou (Kouhei Sutou) over 2 years ago
I like this change. It's unbelievable.
I thought that I don't like this feature because I was confused Python's backtrace behavior (most recent call last).
I used trunk in a few weeks but I was not confused the current behavior. Instead it was convenient.
I noticed that I confirm error message and then backtrace on error. It was convenient that error message is shown at the last. I could confirm backtrace from the bottom to the top naturally.
Python's backtrace behavior doesn't show index:
def a(): x() def b(): a() b()
% python /tmp/a.py Traceback (most recent call last): File "/tmp/a.py", line 7, in <module> b() File "/tmp/a.py", line 5, in b a() File "/tmp/a.py", line 2, in a x() NameError: global name 'x' is not defined
Ruby 2.5's one shows index:
def a x end def b a end b
% ruby /tmp/a.rb Traceback (most recent call last): 2: from /tmp/a.rb:9:in `<main>' 1: from /tmp/a.rb:6:in `b' /tmp/a.rb:2:in `a': undefined local variable or method `x' for main:Object (NameError)
It may be helpful to recognize backtrace order.
I've added the same behavior to test-unit and released a new version.
Updated by aeroastro (Takumasa Ochi) over 2 years ago
Although I am not a Ruby committer, IMHO, I do not think the current implementation
is the best way to fully address the reporter's concern.
As written in this issue's description section, reversing the backtrace is a
solution which only works in the environments where you read the log from bottom
to top like terminals.
Nowadays, it is becoming more and more common to read the log from top to bottom
in other environments like CI report (e.g. Jenkins, Travis, and so on),
web-based error dashboard (e.g. Stack Driver), interactive applications
(e.g. Jupyter). Current Ruby 2.5's behavior is to reverse backtrace when STDERR
is unchanged and a tty. Therefore we can still read the backtrace from top to
bottom in those situations. However, this conditional reversing lacks consistency
and is confusing. For example, just a redirection can change the behavior of output.
At the same time, I think we need to clarify what the problem actually is.
If a lot of people using Rails are suffering from huge backtraces, which can be assumed from
the word "every project" and "tailing the production logs", ActiveSupport::BacktraceCleaner
can solve the problem in a more sophisticated way. It convert the huge backtrace to
a very compact one by filtering out irrelevant lines which belong to Rails framework.
This solution works well regardless of the way how we read the log because the backtrace
is short and simple.
If people developing Rails itself are suffering from huge backtraces, although conditional
reversing could work to some extent, IMHO, we need to consider a solution with fewer
and minor side effects.
Updated by ioquatix (Samuel Williams) almost 2 years ago
This is possibly one of the most irritating changes to Ruby recently. Now, every time I read back trace, I have to check it carefully.
Is it top to bottom or bottom to top?
How is this confusion made worse?
- Using multiple versions of Ruby, or different interpreters that retain the old behaviour.
- Using testing frameworks and logging frameworks that retain the old behaviour.
This is a case where I think the benefit was significantly overshadowed by the cost to end users. It's now very, very confusing.
Updated by mame (Yusuke Endoh) over 1 year ago
Over one year has passed since the backtrace order was reversed. But I'm not still used to the new order.
I agree with Samuel's points. In addition, the old order was more useful because it shows the last debug output and the exception message in one place.
$ ruby24 test.rb ... ... "debug print" "debug print" "the last debug print" test.rb:X:in 'buggy_func': exception message from test.rb:X:in `foo' from test.rb:X:in `bar' ... ...
In the above output,
"the last debug output" and
test.rb:X:in 'buggy_func': exception message are placed in one place. It is easy to understand the situation and to start debugging.
However, the current behavior separates the two. This is very frastrating.
$ ruby25 test.rb ... ... "debug print" "debug print" "the last debug print" ... ... from test.rb:X:in `bar' from test.rb:X:in `foo' test.rb:X:in 'buggy_func': exception message
Is there any chance to revert the change?
Updated by shevegen (Robert A. Heiler) over 1 year ago
I think I agree with mame - perhaps it should be reverted for now.
There was another ruby hacker from japan who wrote, some time ago
(a year or two?), that he was confused about it too; I don't remember
where it was but I think it was in a standalone proposal some time
In my opinion, the best would be to find a way to be able to
fully customize the behaviour/display that ruby uses for reporting
warnings/errors, with a default chosen that may be most appropriate
for the most common ways to display the issues at hand (I have no
preference to the default chosen here, but perhaps we should
revert to the behaviour ruby used to use; and then allow full
customization for people to adapt it to their own personal needs).
I assume that matz may not have a huge preference either, so
perhaps we should (lateron?) focus on some way to be able to
customize how ruby treats warnings/errors or rather, display
them. An obvious way may be to allow for environment variables.
An additional way may be to pick something at compile time (so
that people can customize it for their own host system, as a
default), and perhaps also a --user flag directive of some
sorts; and perhaps additionally something like $VERBOSE, but
through some core method call or something instead.
I should, however had, also note that while I think I prefer
the old behaviour, to me personally it is not a huge deal either
way - I just can understand everyone who may not like the
chosen default as-is. The only thing that I personally found hard
was when the filenames are very long and the error is somewhere
deep down in code that gets called by lots of other methods in
different files - then the error messages are "overflowing" to
the right of my screen display, so in this case, I would prefer
a shorter message, or perhaps split up onto several lines; I kind
of focus on the left hand side of my screen normally. But again,
it's not really something I personally am deeply invested - I am
personally am more looking as to how mjit is progressing. :)