From: ko1@...
Date: 2015-02-23T09:49:43+00:00
Subject: [ruby-core:68241] [Ruby trunk - Bug #10561] Improve function of Thread::Backtrace::Location #path and #absolute_path

Issue #10561 has been updated by Koichi Sasada.


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

I guess the reason is that Matz thought backtrace should be simple for main script.


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

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