[ruby-core:68245] [Ruby trunk - Bug #10561] Improve function of Thread::Backtrace::Location #path and #absolute_path

Issue #10561 has been updated by Yorick Peterse.


It's fine for the methods to do different things, the naming however is a bit
confusing. Using `path` doesn't clearly state when it's absolute and when it's
relative. Perhaps `script_path` would make more sense.

Merging the two is also fine, although it could potentially break code depending
on the current behaviour of `path`, thus it would have to be done with some
care.

----------------------------------------
Bug #10561: Improve function of Thread::Backtrace::Location #path and #absolute_path
https://bugs.ruby-lang.org/issues/10561#change-51606

* Author: Sam Saffron
* Status: Open
* Priority: Normal
* Assignee: 
* ruby -v: 2.2.0
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
I was working on this issue in Rails and hit an area where Backtrace Location can be improved

https://github.com/rails/rails/pull/17782


1. It is undefined in the documentation how #absolute_path should operate when #path is invalid (in case of instance eval)
2. There are a few conditions where #path and #absolute_path can return nil, this forces extra protection code when parsing paths to check for nil. (for example getting filename)  

Suggestions:

1. Instead of returning Qnil from location_path and location_absolute_path on invalid conditions, return the string "(unknown)" which is easier to parse and sticks out better in a big backtrace. There is precedent here with the string "(eval)"
2. If path is invalid have absolute_path return "(unknown)", define that in the documentation
3. (possible) add an additional method on caller_location called #filename so people stop parsing filename from #path and #absolute_path
4. Evaluate if it makes sense to have #path and #absolute_path in the API as both methods can return full paths so the semantic difference is subtle. 



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