From: Alex Chaffee <alexch@...>
Date: 2007-11-13T05:20:07+09:00
Subject: Re: Hiding backtrace with "x levels"

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