[ruby-core:53484] Re: [CommonRuby - Feature #7895] Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locations

On Sat, Mar 16, 2013 at 02:12:03AM +0900, headius (Charles Nutter) wrote:
> 
> Issue #7895 has been updated by headius (Charles Nutter).
> 
> 
> kallistec (Daniel DeLeo) wrote:
> > 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. 
> > 
> > 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.

Rails uses set_backtrace, and is basically in the same boat.

> 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?)
> 
> Some specifications I proposed before:
> 
> * If an exception has had no modifications applied, #backtrace and #backtrace_locations will be the same content (in different form, obviously).
> * If an exception has had #set_backtrace_locations (#backtrace_locations=) called, #backtrace and #backtrace_locations will reflect the new content.
> * 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).
> 
> So basically #backtrace_locations is the future path for dealing with exception data and #backtrace (probably deprecated in future) only piggy-backs off it.
> 
> Seem reasonable?

This is something we could work with. :-)

-- 
Aaron Patterson
http://tenderlovemaking.com/