Issue #10561 has been updated by Koichi Sasada.


[MAYBE IT SHOULD BE DIFFERENT TICKET]

How about to unify #path and #absolute_path?
Returning absolute path on both methods.

When I made this API, there are three types path, (1) path of main script (partial path) and (2) paths of required files which is absolute path as described in this ticket and (3) string passed by "eval" methods (or "-e" command line option).

I think we don't need to separate (1) and (2). (1) can be absolute path.

What do you think?


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

* 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/