https://redmine.ruby-lang.org/https://redmine.ruby-lang.org/favicon.ico?17113305112013-02-21T06:53:18ZRuby Issue Tracking SystemRuby master - Feature #7895: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locationshttps://redmine.ruby-lang.org/issues/7895?journal_id=366872013-02-21T06:53:18Zko1 (Koichi Sasada)
<ul></ul><p>(2013/02/21 6:02), headius (Charles Nutter) wrote:</p>
<blockquote>
<p>I propose that if you set_backtrace, you are already breaking the ability to get structured Location elements, so set_backtrace should cause backtrace_locations to return nil or an empty array (probably an empty array, so it can always be expected to be non-nil).</p>
<p>We could consider also adding set_backtrace_locations as a way to set Location elements into the exception.</p>
</blockquote>
<p>I want to agree with you. But I feel there are worries.</p>
<p>(a) Exception#set_backtrace are used by frameworks</p>
<p>Maybe Exception#set_backtrace are used by frameworks such as Rails. So<br>
that your proposal "if Exception#set_backtrace was called, disable<br>
Exception#backtrace_locations" seems bad idea because 99% of people<br>
works on Rails (*1) and 99% (*1) of people can't use<br>
Exception#backtrace_locations.</p>
<p>*1: joking.</p>
<p>(b) We can't use Exception#backtrace_locations in library</p>
<p>If you write a library using Exception#backtrace_locations, this library<br>
can't use with this library with programs using Exception#set_backtrace.<br>
As I pointed out by (a), we can't mix with frameworks.</p>
<hr>
<p>Other options:</p>
<p>(1) Make Exception#set_backtrace parse each backtrace lines.<br>
Problem:<br>
(1-p1) Parsing is difficult. Path format is OS dependent.<br>
(1-p2) How to parse not well-formed line?</p>
<p>(2) Deprecate set_backtrace and replace it with set_backtrace_locations<br>
Problem:<br>
(2-p1) Compatibility!!!</p>
<p>(1) with heuristics parsing technique is pragmatic?</p>
<p>--<br>
// SASADA Koichi at atdot dot net</p> Ruby master - Feature #7895: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locationshttps://redmine.ruby-lang.org/issues/7895?journal_id=366892013-02-21T08:53:15Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>On Thu, Feb 21, 2013 at 8:36 AM, SASADA Koichi <a href="mailto:ko1@atdot.net" class="email">ko1@atdot.net</a> wrote:</p>
<blockquote>
<p>I want to agree with you. But I feel there are worries.</p>
</blockquote>
<p>How about #backtrace/#set_backtrace and<br>
#backtrace_locations/#set_backtrace_locations are completely<br>
<em>separate</em> representations of the backtrace? That preserves backward<br>
compatibility while providing a path forward to the more structured<br>
backtrace form. I think it's reasonable to expect that the<br>
unstructured backtrace form doesn't update or break the structured<br>
form.</p>
<ul>
<li>Charlie</li>
</ul> Ruby master - Feature #7895: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locationshttps://redmine.ruby-lang.org/issues/7895?journal_id=367002013-02-21T15:53:10Zko1 (Koichi Sasada)
<ul></ul><p>(2013/02/21 8:50), Charles Oliver Nutter wrote:</p>
<blockquote>
<p>On Thu, Feb 21, 2013 at 8:36 AM, SASADA Koichi <a href="mailto:ko1@atdot.net" class="email">ko1@atdot.net</a> wrote:</p>
<blockquote>
<p>I want to agree with you. But I feel there are worries.</p>
</blockquote>
<p>How about #backtrace/#set_backtrace and<br>
#backtrace_locations/#set_backtrace_locations are completely<br>
<em>separate</em> representations of the backtrace? That preserves backward<br>
compatibility while providing a path forward to the more structured<br>
backtrace form. I think it's reasonable to expect that the<br>
unstructured backtrace form doesn't update or break the structured<br>
form.</p>
</blockquote>
<p>I think it is reasonable.</p>
<p>(3) Separate Exception#bactrace and Exception#backtrace_locations<br>
Problems:<br>
(3-p1) which should output as an error backtrace when interpreter dies.<br>
(3-p2) may introduce confusion?</p>
<p>Other comments and ideas are welcome.</p>
<p>--<br>
// SASADA Koichi at atdot dot net</p> Ruby master - Feature #7895: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locationshttps://redmine.ruby-lang.org/issues/7895?journal_id=367082013-02-21T20:53:17Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>On Thu, Feb 21, 2013 at 5:47 PM, SASADA Koichi <a href="mailto:ko1@atdot.net" class="email">ko1@atdot.net</a> wrote:</p>
<blockquote>
<p>I think it is reasonable.</p>
<p>(3) Separate Exception#bactrace and Exception#backtrace_locations<br>
Problems:<br>
(3-p1) which should output as an error backtrace when interpreter dies.</p>
</blockquote>
<p>Good question! I was wondering about this too. Does #backtrace remain<br>
the canonical stack trace source, or do we move to<br>
#backtrace_locations? Perhaps there's a heuristic necessary here to<br>
support forward migration. To be honest, the ability to replace the<br>
stack trace has always bothered me a bit, since it means a program<br>
could potentially hide where an error occurs. I feel like if the<br>
exception bubbles all the way out, you should get a proper trace. I'm<br>
probably missing the use case where you want to provide a customized<br>
trace, though.</p>
<blockquote>
<p>(3-p2) may introduce confusion?</p>
</blockquote>
<p>I think this is unavoidable, to some extent. We would like to migrate<br>
people toward using the structured backtrace, but it is not<br>
backward-compatible with the unstructured backtrace. So...we make a<br>
decision: prioritize the structured version or prioritize the<br>
unstructured version? I tend toward the ideal future and would<br>
emphasize the structured version as much as possible...meaning that<br>
interpreter death uses backtrace_locations, unless set_backtrace has<br>
been used to provide the old-style trace. As I say above, there's<br>
probably a reasonable heuristic possible here based on what we want to<br>
encourage people to use.</p>
<p>Thinking through this a bit...</p>
<ul>
<li>Base all backtrace output on the backtrace_locations content unless<br>
otherwise indicated.</li>
<li>If you specify a backtrace at construction time, inspect whether it<br>
is string content (old style) or Location content (new style).</li>
<li>Any modification of the string-based #backtrace overrides<br>
#backtrace_locations for printing purposes. If #backtrace has not been<br>
set, either via constructor or via #set_backtrace, then we generate it<br>
based on #backtrace_locations.</li>
</ul>
<p>Basically, #backtrace_locations is the primary source of backtrace<br>
data, unless the user provides an old-style #backtrace or uses<br>
#set_backtrace to do something custom.</p>
<p>Of course #set_backtrace_locations should enforce that the array<br>
provided is actually Location objects.</p>
<ul>
<li>Charlie</li>
</ul> Ruby master - Feature #7895: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locationshttps://redmine.ruby-lang.org/issues/7895?journal_id=374142013-03-09T17:08:14Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>What's next here? I'm about to implement caller_locations in JRuby, so I'm close to being able to prototype this feature request too.</p> Ruby master - Feature #7895: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locationshttps://redmine.ruby-lang.org/issues/7895?journal_id=374832013-03-11T10:53:14Zko1 (Koichi Sasada)
<ul></ul><p>(2013/03/09 17:08), headius (Charles Nutter) wrote:</p>
<blockquote>
<p>What's next here? I'm about to implement caller_locations in JRuby, so I'm close to being able to prototype this feature request too.</p>
</blockquote>
<p>Now, only two attendees (you and I).<br>
I want to get other opinions, especially users of #set_backtrace().</p>
<p>--<br>
// SASADA Koichi at atdot dot net</p> Ruby master - Feature #7895: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locationshttps://redmine.ruby-lang.org/issues/7895?journal_id=375182013-03-12T05:03:51Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>For now I have implemented it in JRuby.</p>
<p>Here's the commit: <a href="https://github.com/jruby/jruby/commit/281ead709e1e855b552a42e86e48f8f91ca8ebb5" class="external">https://github.com/jruby/jruby/commit/281ead709e1e855b552a42e86e48f8f91ca8ebb5</a></p>
<p>It works simply enough; Exception#backtrace_locations always reflects the original exception trace and (at least for now) it can't be modified.</p>
<pre><code>irb(main):004:0> def foo; raise; end
=> nil
irb(main):005:0> def bar; 1.times { foo }; end
=> nil
irb(main):006:0> ex = begin; bar; rescue; $!; end
=> RuntimeError
irb(main):007:0> ex.backtrace_locations.each {|loc| puts "method: #{loc.label}, line: #{loc.lineno}"}
method: foo, line: 4
method: bar, line: 5
method: times, line: 271
method: bar, line: 5
method: evaluate, line: 6
</code></pre> Ruby master - Feature #7895: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locationshttps://redmine.ruby-lang.org/issues/7895?journal_id=375362013-03-13T00:57:41Zkallistec (Daniel DeLeo)dan@kallistec.com
<ul></ul><p>Hi, I work on Opscode's Chef, a server configuration framework. I have an interest in both parts of this topic. In Chef, we use set_backtrace but we also parse backtrace lines to find relevant code in our error messages.</p>
<p>When we use set_backtrace, it is because we are catching an exception and then re-raising as either the same exception class or as a different exception class. Our goal here is to add context to exceptions that would otherwise be very difficult for the end user to understand.</p>
<p>We somewhat recently rewrote our error messaging to be more user friendly. To do this, we need to process backtraces and filter out framework code (leaving only user code) and then use regular expressions to find the relevant line numbers. Having structured backtrace data would be much better than what we're doing now.</p>
<p>For our use case, we need a way to set backtrace_locations from one exception to another. We currently only use set_backtrace immediately after creating an exception, so it would be fine if we could pass the needed data into the constructor, as long as there is a reasonable way to make the method signatures in current ruby compatible via monkey patching or #respond_to?</p> Ruby master - Feature #7895: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locationshttps://redmine.ruby-lang.org/issues/7895?journal_id=376322013-03-16T02:12:02Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>kallistec (Daniel DeLeo) wrote:</p>
<blockquote>
<p>Hi, I work on Opscode's Chef, a server configuration framework. I have an interest in both parts of this topic. In Chef, we use set_backtrace but we also parse backtrace lines to find relevant code in our error messages.</p>
<p>When we use set_backtrace, it is because we are catching an exception and then re-raising as either the same exception class or as a different exception class. Our goal here is to add context to exceptions that would otherwise be very difficult for the end user to understand.</p>
</blockquote>
<p>So, as long as you'd be happy with Thread::Backtrace::Location's elements, it should just be a matter of creating a new Array of Location objects and passing it to an hypothetical set_backtrace_locations (or hey, let's get crazy and call it backtrace_locations= perhaps?)</p>
<p>Some specifications I proposed before:</p>
<ul>
<li>If an exception has had no modifications applied, #backtrace and #backtrace_locations will be the same content (in different form, obviously).</li>
<li>If an exception has had #set_backtrace_locations (#backtrace_locations=) called, #backtrace and #backtrace_locations will reflect the new content.</li>
<li>If an exception has had #set_backtrace called, #backtrace will reflect the new content but #backtrace_locations will not (due to the impossibility of guaranteeing #set_backtrace lines will parse into Location objects).</li>
</ul>
<p>So basically #backtrace_locations is the future path for dealing with exception data and #backtrace (probably deprecated in future) only piggy-backs off it.</p>
<p>Seem reasonable?</p> Ruby master - Feature #7895: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locationshttps://redmine.ruby-lang.org/issues/7895?journal_id=376692013-03-17T05:53:11ZAnonymous
<ul></ul><p>On Sat, Mar 16, 2013 at 02:12:03AM +0900, headius (Charles Nutter) wrote:</p>
<blockquote>
<p>Issue <a class="issue tracker-2 status-1 priority-4 priority-default" title="Feature: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locations (Open)" href="https://redmine.ruby-lang.org/issues/7895">#7895</a> has been updated by headius (Charles Nutter).</p>
<p>kallistec (Daniel DeLeo) wrote:</p>
<blockquote>
<p>Hi, I work on Opscode's Chef, a server configuration framework. I have an interest in both parts of this topic. In Chef, we use set_backtrace but we also parse backtrace lines to find relevant code in our error messages.</p>
<p>When we use set_backtrace, it is because we are catching an exception and then re-raising as either the same exception class or as a different exception class. Our goal here is to add context to exceptions that would otherwise be very difficult for the end user to understand.</p>
</blockquote>
</blockquote>
<p>Rails uses set_backtrace, and is basically in the same boat.</p>
<blockquote>
<p>So, as long as you'd be happy with Thread::Backtrace::Location's elements, it should just be a matter of creating a new Array of Location objects and passing it to an hypothetical set_backtrace_locations (or hey, let's get crazy and call it backtrace_locations= perhaps?)</p>
<p>Some specifications I proposed before:</p>
<ul>
<li>If an exception has had no modifications applied, #backtrace and #backtrace_locations will be the same content (in different form, obviously).</li>
<li>If an exception has had #set_backtrace_locations (#backtrace_locations=) called, #backtrace and #backtrace_locations will reflect the new content.</li>
<li>If an exception has had #set_backtrace called, #backtrace will reflect the new content but #backtrace_locations will not (due to the impossibility of guaranteeing #set_backtrace lines will parse into Location objects).</li>
</ul>
<p>So basically #backtrace_locations is the future path for dealing with exception data and #backtrace (probably deprecated in future) only piggy-backs off it.</p>
<p>Seem reasonable?</p>
</blockquote>
<p>This is something we could work with. :-)</p>
<p>--<br>
Aaron Patterson<br>
<a href="http://tenderlovemaking.com/" class="external">http://tenderlovemaking.com/</a></p> Ruby master - Feature #7895: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locationshttps://redmine.ruby-lang.org/issues/7895?journal_id=386292013-04-17T02:54:23Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>What's the next step here? Do we need a patch to proceed? It seems like this feature is universally liked.</p> Ruby master - Feature #7895: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locationshttps://redmine.ruby-lang.org/issues/7895?journal_id=386392013-04-17T04:59:35Zenebo (Thomas Enebo)tom.enebo@gmail.com
<ul></ul><p>Has anyone talked about .backtrace returning a subclass of String (or singleton) which duck-types to the same methods as Location? It is arguably hacky and would not work for === but it would still allow them to be used in a compatible way. Or maybe .backtrace_locations provides this special string. If set_backtrace is used it will just be dressed up with this methods it .backtrace (or .backtrace_locations) is called.</p> Ruby master - Feature #7895: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locationshttps://redmine.ruby-lang.org/issues/7895?journal_id=386402013-04-17T07:32:37Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>I think that was tossed around on IRC or somewhere. It would certainly work, but it feels a little too hacky to me.</p>
<p>You'd also never be able to rely on the String objects from #backtrace actually being Location-like, since set_backtrace would clear them. I still feel like this is the best plan:</p>
<ul>
<li>backtrace_locations is the master copy of backtrace data</li>
<li>set_backtrace_locations can be used to modify it (optional...I have no strong opinion)</li>
<li>backtrace generates based on backtrace_locations unless explicitly set with set_backtrace</li>
<li>setting backtrace to nil reverts it to using backtrace_locations (maybe?)</li>
</ul> Ruby master - Feature #7895: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locationshttps://redmine.ruby-lang.org/issues/7895?journal_id=388482013-04-24T06:22:33Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>I should mention that Exception#backtrace_locations is implemented in JRuby on master (1.7.4) in ruby 2.0 mode. I had not intended to add it before MRI, but it's there. We may remove it before release, but this would give folks a change to play with it on a standard build (jruby master).</p> Ruby master - Feature #7895: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locationshttps://redmine.ruby-lang.org/issues/7895?journal_id=389722013-04-28T07:59:11Zko1 (Koichi Sasada)
<ul></ul><p>(2013/04/17 2:54), headius (Charles Nutter) wrote:</p>
<blockquote>
<p>What's the next step here? Do we need a patch to proceed? It seems like this feature is universally liked.</p>
</blockquote>
<p>I don't have any objection about it now.</p>
<p>Patches are welcome! :)</p>
<p>Make another issue for CRuby/trunk?</p>
<p>--<br>
// SASADA Koichi at atdot dot net</p> Ruby master - Feature #7895: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locationshttps://redmine.ruby-lang.org/issues/7895?journal_id=420372013-09-27T20:12:11Zheadius (Charles Nutter)headius@headius.com
<ul></ul><p>I have filed <a href="https://bugs.ruby-lang.org/issues/8960" class="external">https://bugs.ruby-lang.org/issues/8960</a> to get this feature added to MRI. It is already available in JRuby.</p> Ruby master - Feature #7895: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locationshttps://redmine.ruby-lang.org/issues/7895?journal_id=421222013-10-01T09:39:40Zheadius (Charles Nutter)headius@headius.com
<ul><li><strong>Target version</strong> set to <i>Ruby 2.1.0</i></li></ul> Ruby master - Feature #7895: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locationshttps://redmine.ruby-lang.org/issues/7895?journal_id=955622021-12-23T23:43:55Zhsbt (Hiroshi SHIBATA)hsbt@ruby-lang.org
<ul><li><strong>Project</strong> changed from <i>14</i> to <i>Ruby master</i></li><li><strong>Target version</strong> deleted (<del><i>Ruby 2.1.0</i></del>)</li></ul>