Open yar opened 9 years ago
I'm not sure if rails sets this up correctly, but you should be able to do cd-cause
to jump to the original raise site.
Let me know if not.
Thanks. Alas, cd-cause leaves pry in the same scope.
I uploaded a minimal app that illustrates the problem: https://github.com/yar/p-r-test
I can confirm I have the same issue. Neither web-console is helpful in this case. My code is like this in a view (using simple_form):
= f.association :equipment_items,
collection: car_equipment_items_ordered(@car),
as: :grouped_select,
label_method: :name,
value_method: :id,
group_method: :category,
group_label_method: :to_s,
input_html: {data: {equipment_items_url: url_for(controller: 'api/v1/equipment_items', action: 'create')}}
And the backtrace looks all right:
[12] pry(#<ActionView::Template>)> pry-backtrace
Backtrace:
--
...gems/actionview-5.0.0.1/lib/action_view/helpers/form_options_helper.rb:395:in `options_from_collection_for_select'
...gems/actionview-5.0.0.1/lib/action_view/helpers/form_options_helper.rb:457:in `block in option_groups_from_collection_for_select'
...gems/actionview-5.0.0.1/lib/action_view/helpers/form_options_helper.rb:456:in `map'
...gems/actionview-5.0.0.1/lib/action_view/helpers/form_options_helper.rb:456:in `option_groups_from_collection_for_select'
...gems/actionview-5.0.0.1/lib/action_view/helpers/tags/grouped_collection_select.rb:23:in `render'
...gems/actionview-5.0.0.1/lib/action_view/helpers/form_options_helper.rb:258:in `grouped_collection_select'
...gems/actionview-5.0.0.1/lib/action_view/helpers/form_options_helper.rb:841:in `grouped_collection_select'
...gems/simple_form-3.3.1/lib/simple_form/inputs/grouped_collection_select_input.rb:9:in `input'
But nesting
outputs the view as top level and nothing else
[13] pry(#<ActionView::Template>)> nesting
Nesting status:
--
0. #<ActionView::Template> (Pry top level)
So I can't cd
to another stack to find out why my input to the method is incorrect.
Not sure if we shouldn't be filing this with Actionview
As a workaround, in Haml, I add a - Pry.rescue do
above the line and indent the next one if I know it could be problematic.
The merged PR #106 solved this problem for me. It just isn't a part of the most recent version of this gem on RubyGems.
pry-rescue 1.4.2 pry-stack_explorer 0.4.9.2 rails 3.2.21 rspec 3.3.0 rspec-rails 3.3.3
The following occurs in my testing: rails template calls a helper method. The helper method calls a method on my object, and inside it, an exception occurs. The local variables in that object method at the time of the exception are important and I am trying to study them with pry-rescue.
"pry-backtrace" correctly shows my PORO at the very top.
However, "ls" suggests that I am not inside that method, but rather in the scope of the template itself. Local variables of my object are not visible from that context.
I see that Rails tinkers with the original exception, re-raising from a different context, as ActionView::Template::Error.
So this is not really a bug of pry-backtrace, but rather a limitation of its use with Rails. Is there a way to overcome this problem?