Hiding backtrace with "x levels"

[Brian Takita]

I must say hiding the backtrace with x levels is a major annoyance.
I know the "solution" is to "simply put begin/rescue around the
error", but thats asinine.

I noticed that the code that does this is deep in ruby's C implementation.
Has anybody made ruby show the entire backtrace? I guess I could on my
machine, but I'd rather not have to change the C code.
Can this be resolved Ruby 1.9, if it is not already?

Thanks,
Brian Takita

 

[Robert Klemme]

I must say hiding the backtrace with x levels is a major annoyance.
I know the "solution" is to "simply put begin/rescue around the
error", but thats asinine.

Since when is proper error handling "asinine"?

I noticed that the code that does this is deep in ruby's C implementation.
Has anybody made ruby show the entire backtrace? I guess I could on my
machine, but I'd rather not have to change the C code.

Then just do it in Ruby code - you even know the implementation already.

Can this be resolved Ruby 1.9, if it is not already?

I can only speculate about the reasons for the current implementation
(for example, to not clutter logfiles with the default stack dump) but I
find the grounds on which you request a change which potentially affects
the whole community very weak.

robert

 

[Alex Young]

Since when is proper error handling "asinine"?


Then just do it in Ruby code - you even know the implementation already.


I can only speculate about the reasons for the current implementation
(for example, to not clutter logfiles with the default stack dump) but I
find the grounds on which you request a change which potentially affects
the whole community very weak.

I obviously can't speak for the OP, but I'd find a command-line option
to switch the console stack dump to full depth very handy.

 

[Brian Takita]

Since when is proper error handling "asinine"?

I think you misunderstood me. To express this misunderstanding, I'll
repeat what you are saying according to what I'm saying.
"In ruby you should have a begin/rescue block around every line of your code".
I'm sure you are not proposing that as a good pattern, but I digress.

I find hiding the stack trace to be unproductive. Its one more step I
need to do. It also hides information from production errors, which is
not a good thing.

Then just do it in Ruby code - you even know the implementation already.


I can only speculate about the reasons for the current implementation
(for example, to not clutter logfiles with the default stack dump) but I
find the grounds on which you request a change which potentially affects
the whole community very weak.

I think a lot of people would agree with this. Anybody who has had a
production bug obfuscated by '... n levels ...' would agree with me.
Its simply not user friendly. It may be ruby core developer friendly,
but its not ruby developer friendly, imho.
If you like obfuscation, then go ahead and disagree with me.

 

[Alex Chaffee]

Brian is right -- the current implementation of backtrace printing is
definitely broken. The whole reason for printing a backtrace is so you
can track down not only what function the error occurred in, but what
functions were calling it, recursively back to the root. The question
should be, what is gained by omitting a swath of callers in the middle
of the trace? I can think of only one reason -- readability -- but
that should not be at the expense of the basic functionality.

At some point in its history (1.3?) Java started eliding stack traces,
but their algorithm has an important difference from Ruby's current
broken one: it only elides lines that have *already appeared* in
previous stack traces in this process, so you don't lose any
information. Ruby's code doesn't do this -- it just cuts out callers
wantonly.

Especially in programs using a framework -- like Rails or Test::Unit
-- the first few callers are meaningless since they're just framework
code. Likewise, the most recent few callers are not helpful since
they're often inside a library or common routine that's got dozens of
callers. You need to see the middle part to find out who's the real
culprit.

Finally, Brian's point about production logs must be underlined.
Sometimes all you have to go on to track down a sporadic failure is
the backtrace that got spit out into the logs. In that case, why would
you ever want to remove the info? It's almost like Ruby is taking
perverse pleasure in showing us *almost* enough information but then,
at the last minute, withholding what we need. Ruby is such a
tease!

- A

 

[Roger Pack]

I obviously can't speak for the OP, but I'd find a command-line option
to switch the console stack dump to full depth very handy.

Amen.

 

[Alex Chaffee]

Amen.

At the risk of appearing too doctrinaire, I think a command-line
option is not the right solution here. It should work correctly by
default. In the "production logs" use case I mentioned before, it is
very likely that the code that actually launches ruby is buried
somewhere deep in a system startup file, which means that we'd have to
patch all such files to pass in the "--backtraces-work-correctly" flag
on every system, which sounds like a logistical and political
nightmare.

So has anyone come up with answer to what is gained by omitting a
swath of callers in the middle of the trace? Does anyone have a
reason why the current behavior is not incorrect?

- A

 

[Alex Young]

At the risk of appearing too doctrinaire, I think a command-line
option is not the right solution here. It should work correctly by
default.

Ordinarily I'd agree. However, leaving the default behaviour unchanged
means you can't break anything that depends on it. I'd like to see a
change in the default for 1.9 (untested, so I don't know what the
current behaviour actually is...) but it might be to intrusive for 1.8.

In the "production logs" use case I mentioned before, it is
very likely that the code that actually launches ruby is buried
somewhere deep in a system startup file, which means that we'd have to
patch all such files to pass in the "--backtraces-work-correctly" flag
on every system, which sounds like a logistical and political
nightmare.

It's not quite that complicated - either replacing /usr/bin/ruby with a
shell script shim or getting the command-line switch into RUBYOPT (which
I think is the correct method) would do it. Either way it's a fix in a
single place (per system).

 

[Alex Young]

Ordinarily I'd agree. However, leaving the default behaviour unchanged
means you can't break anything that depends on it. I'd like to see a
change in the default for 1.9 (untested, so I don't know what the
current behaviour actually is...) but it might be to intrusive for 1.8.

I've just tested it on 1.9 HEAD, it looks like you get the full stack
dump. Yay!

 

[Alex Chaffee]

I've just tested it on 1.9 HEAD, it looks like you get the full stack
dump. Yay!

Yay indeed!

BTW, here's a real-world example of why eliding the stack trace is bad
news. I'm using deep_test and I've got a bunch of ruby classes that
are all communicating with each other. Can you tell me which class/
line of code of mine or of deep_test is provoking this exception?

..(druby://Macintosh.local:54372) /usr/local/lib/ruby/1.8/drb/drb.rb:
736:in `open': druby://localhost:42531 - #<Errno::ECONNREFUSED:
Connection refused - connect(2)> (DRb:RbConnError)
from (druby://Macintosh.local:54372) /usr/local/lib/ruby/1.8/drb/
drb.rb:729:in `each'
from (druby://Macintosh.local:54372) /usr/local/lib/ruby/1.8/drb/
drb.rb:729:in `open'
from (druby://Macintosh.local:54372) /usr/local/lib/ruby/1.8/drb/
drb.rb:1189:in `initialize'
from (druby://Macintosh.local:54372) /usr/local/lib/ruby/1.8/drb/
drb.rb:1169:in `new'
from (druby://Macintosh.local:54372) /usr/local/lib/ruby/1.8/drb/
drb.rb:1169:in `open'
from (druby://Macintosh.local:54372) /usr/local/lib/ruby/1.8/drb/
drb.rb:1085:in `method_missing'
from (druby://Macintosh.local:54372) /usr/local/lib/ruby/1.8/drb/
drb.rb:1103:in `with_friend'
from (druby://Macintosh.local:54372) /usr/local/lib/ruby/1.8/drb/
drb.rb:1084:in `method_missing'
... 38 levels...
from /usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1708:in
`run'
from /usr/local/lib/ruby/gems/1.8/gems/rake-0.7.3/bin/rake:7
from /usr/local/bin/rake:16:in `load'
from /usr/local/bin/rake:16

Didn't think so

- Alex