I updated a few gems (carrierwave, fog, sdoc in particular). I'm now experiencing a weird issue if I try to execute a method that doesn't exist. Pry completely crashes every time. Here is an example:
Loading development environment (Rails 4.2.11)
[1] pry(main)> d
Traceback (most recent call last):
bin/rails: undefined method `[]' for nil:NilClass (NoMethodError)
I have never seen this issue before so I don't know where to start. I use pry-rails if that helps.
When I load the rails console using spring, I get this:
Loading development environment (Rails 4.2.11)
[1] [time_capsule][development] pry(main)> d
Traceback (most recent call last):
/Users/brandoncc/.rbenv/versions/2.5.3/lib/ruby/gems/2.5.0/gems/spring-2.0.2/lib/spring/application.rb:171:in `fork': undefined method `reject!' for nil:NilClass (NoMethodError)
What is your pryrc? Pry and pry-rails versions?
I commented it out and still got the same error, but this is my .pryrc:
require 'hirb'
rescue LoadError
# Missing goodies, bummer
end
if defined? Hirb
# Slightly dirty hack to fully support in-session Hirb.disable/enable toggling
Hirb::View.instance_eval do
def enable_output_method
@output_method = true
@old_print = Pry.config.print
Pry.config.print = proc do |*args|
Hirb::View.view_or_page_output(args[1]) || @old_print.call(*args)
end
end
def disable_output_method
Pry.config.print = @old_print
@output_method = nil
end
end
Hirb.enable
end
if Pry::Prompt[:rails]
Pry.config.prompt = Pry::Prompt[:rails][:value]
end
pry 0.12.2 and pry-rails 0.3.8.
Looks like the Spring one comes from here:
Probably caused by some other issue, but IIRC, they shouldn't depend on having a backtrace like that. Don't remember offhand how to get an exception without a backtrace, but still, they should probably change it to if $!&.backtrace (or give the backtrace a default value of empty array, and then call set_backtrace on it).
Anyway, here's how I'd figure it out:
git bisect to find the commit where it breaksOh, one other approach that could work: since you know it blows up there in the spring code, you can probably look at that exception. I'm guessing it's the other exception you see in the first code snippet, but note that you can call Exception#cause to find out if it got raised while trying to deal with some other exception:
def m
raise 'a'
rescue
raise 'b'
end
m rescue $! # => #<RuntimeError: b>
.cause # => #<RuntimeError: a>
Thanks for that @JoshCheek. I went back and applied my updates one at a time and it turned out to be the Ruby 2.5 upgrade that caused the problem. I don't know why I didn't find it before, but this was the exact issue and the offered solution fixed my problem. bundle update binding_of_caller fixed it perfectly.
Thanks again and happy new year!
Thank you @brandoncc, you saved my day! I had the exact same issue
Same here @brandoncc, thanks a lot!
Most helpful comment
Thanks for that @JoshCheek. I went back and applied my updates one at a time and it turned out to be the Ruby 2.5 upgrade that caused the problem. I don't know why I didn't find it before, but this was the exact issue and the offered solution fixed my problem.
bundle update binding_of_callerfixed it perfectly.Thanks again and happy new year!