From: sam.saffron@...
Date: 2014-12-04T22:49:34+00:00
Subject: [ruby-core:66707] [ruby-trunk - Bug #10561] Improve function of Thread::Backtrace::Location #path and #absolute_path

Issue #10561 has been updated by Sam Saffron.


I think the name #path should always refer to a #path of sorts using it as #filename is kind of odd. Which is a big reason I find the duality of #path / #absolute_path confusing. 

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

* Author: Sam Saffron
* Status: Open
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* 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/