From: Charles Oliver Nutter <headius@...>
Date: 2013-02-21T20:51:04+09:00
Subject: [ruby-core:52621] Re: [CommonRuby - Feature #7895][Open] Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locations

On Thu, Feb 21, 2013 at 5:47 PM, SASADA Koichi <ko1@atdot.net> wrote:
> I think it is reasonable.
>
> (3) Separate Exception#bactrace and Exception#backtrace_locations
>   Problems:
>   (3-p1) which should output as an error backtrace when interpreter dies.

Good question! I was wondering about this too. Does #backtrace remain
the canonical stack trace source, or do we move to
#backtrace_locations? Perhaps there's a heuristic necessary here to
support forward migration. To be honest, the ability to replace the
stack trace has always bothered me a bit, since it means a program
could potentially hide where an error occurs. I feel like if the
exception bubbles all the way out, you should get a proper trace. I'm
probably missing the use case where you want to provide a customized
trace, though.

>   (3-p2) may introduce confusion?

I think this is unavoidable, to some extent. We would like to migrate
people toward using the structured backtrace, but it is not
backward-compatible with the unstructured backtrace. So...we make a
decision: prioritize the structured version or prioritize the
unstructured version? I tend toward the ideal future and would
emphasize the structured version as much as possible...meaning that
interpreter death uses backtrace_locations, unless set_backtrace has
been used to provide the old-style trace. As I say above, there's
probably a reasonable heuristic possible here based on what we want to
encourage people to use.

Thinking through this a bit...

* Base all backtrace output on the backtrace_locations content unless
otherwise indicated.
* If you specify a backtrace at construction time, inspect whether it
is string content (old style) or Location content (new style).
* Any modification of the string-based #backtrace overrides
#backtrace_locations for printing purposes. If #backtrace has not been
set, either via constructor or via #set_backtrace, then we generate it
based on #backtrace_locations.

Basically, #backtrace_locations is the primary source of backtrace
data, unless the user provides an old-style #backtrace or uses
#set_backtrace to do something custom.

Of course #set_backtrace_locations should enforce that the array
provided is actually Location objects.

- Charlie