Issue #7895 has been updated by enebo (Thomas Enebo).


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.
----------------------------------------
Feature #7895: Exception#backtrace_locations to go with Thread#backtrace_locations and Kernel#caller_locations
https://bugs.ruby-lang.org/issues/7895#change-38639

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 


Thread#backtrace_locations and Kernel#caller_locations were added in Ruby 2.0.0, but no equivalent method was added to Exception to get backtrace locations. The String format of Exception#backtrace elements makes it difficult to do any inspection of the actual files and lines it reports, so having backtrace_locations would be very useful.

In #7435 ko1 pointed out that Exception defines set_backtrace, which takes an array (presumably of Strings in the same format as Exception#backtrace) and that this would need to be addressed in order to support backtrace_locations. 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).

We could consider also adding set_backtrace_locations as a way to set Location elements into the exception.

An example script where backtrace_locations would be very useful is here (avoiding the need to regexp match to get file and line number): https://gist.github.com/headius/4999244


-- 
http://bugs.ruby-lang.org/