ConradIrwin / pry-rescue

Start a pry session whenever something goes wrong.
MIT License
852 stars 49 forks source link

Exceptions in Rails views are re-raised, losing the original context and making pry-rescue less helpful #89

Open yar opened 9 years ago

yar commented 9 years ago

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?

ConradIrwin commented 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.

yar commented 9 years ago

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

zinkkrysty commented 7 years ago

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.

joallard commented 7 years ago

Not sure if we shouldn't be filing this with Actionview

joallard commented 7 years ago

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.

elliotlarson commented 6 years ago

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.