I've got an issue (this one: How to pass multiple locals to a nested partial) with rails and to figure out what's going on I need to debug the rails internals.
I need to understand which conditions raise the exception in the file
actionpack (3.2.14) lib/action_view/template.rb
At line: 145
How can I debug the framework? I tried to use logger.debug, but it's not available, and I tried with puts, but the console isn't set.
Thanks in advance
Use Pry gem! It is an excellent debugging tool which is easy to setup and has some where powerful features..
Just add 'pry' and 'pry-debugger' gems to your Gemfile (test group) and run bundle and restart the server. After that you just need to set the breakpoint inside your code with command binding.pry. In your case you would want to add breakpoint in your main view with this line:
<% binding.pry %>
Now just trigger the request and the terminal in which you are running the server will stop, giving you prompt so you can interact with the code like in rails console. You have some standard navigation commands such as 'continue', 'next', 'step', 'finish'... you can view the code around you with 'whereami' command, or list the source of methods and classes.
I suggest taking a look at this Pry railscast for more information on how to use Pry.
Related
I am making my way from Django to Rails. So far I just created a new Rails app and found in the Gemfile this line:
# Call 'debugger' anywhere in the code to stop execution and get a
# debugger console
gem 'byebug'
How this supposed to work? Is it as straightforward as it said in the comment? I can put debugger somewhere in code and get a debugger console in my browser?
start rails server
rails s
and monitor the logs.
Now try accessing the page which points to the place where debugger is written in the code
The log will stop at a point where you have put the debugger/byebug word.
You can print out variables at that instant
update for rails 4
On suggestion of Deivid, I would like to quote him here
drop the --debug flag. You don't need to do anything special to make
byebug work in Rails 4. Just require 'byebug' and call byebug
You won't get a debugger in your browser - calling debugger or byebug will drop you into the byebug prompt in the terminal window that was used to run your rails server (note that this is not the same as the rails console - there is a overview of what you can do in the rails debugging guide).
Another tool you may be interested in is the web-console gem (included by default in rails 4.2 and above). This allows you call console (in a controller, view etc.) and will dump you into a browser based IRB session at that point
i want to debug ROR without going through the effort of putting inspect method for every relevant object in the controller as well in the model.is there a better way as we have in Java (Run time debugger using eclipse).i know that I can Use Rails.logger and also make use of rails Console(irb`).i am even aware of debugging/inspecting elements in erb/rb file.Still is there a better,quick and reliable way to debug a Rails app.
There is much better, see this railscats.
It presents two great gems, especially Better Errors
Otherwise, you could use pry with rails, see this railscast.
you can also use pry-rails, pry-debugger and then use binding.pry method in your code and then while using your app you have Rails console available in rails server
Add this lines to your application's Gemfile
group :development do
gem 'ruby-debug19'
end
then run cammand
bundle install
add debugger within your controller or model method, stop the rails server and restart again. Whenever rails found word debugger it stops control at that point. You can easily debug your value or object.
Hope this will helps you.
I was wondering how to exit a controller in rails and get the output up to that point.
In PHP I often used the "exit" when debugging to get only the data processed to that point. I haven't found a sollution to this in rails.
If you get a error further down in the code the view is locked from displaying <%= debug %> information.
Some would suggest console or rescue, and I know about these. But isn't there a simpler solution?
In development mode, I often just use puts or awesome_print to print something to the screen that I ran rails server from. That works pretty well for the simple cases.
For anything more complex than that, I use ruby-debug or pry to drop down into an interactive console when it hits the right point.
I have some editor shortcuts to print one of these two snippets:
require 'pry'; binding.pry
require 'ruby-debug'; debugger
Drop these in your code and you can use IRB to inspect (and manipulate) the state of your program.
I highly recommend you give pry a shot. Check it out here:
http://pryrepl.org/
http://railscasts.com/episodes/280-pry-with-rails
There is also the older ruby-debug:
http://railscasts.com/episodes/54-debugging-with-ruby-debug
Please can you share your approach / methodology to debugging in Ruby / Rails.
I'm busy with the Rails tutorial, and am getting the error:
NoMethodError in UsersController#show
undefined method `microposts' for #<User:0x83b43e8>
And that got me thinking about debugging strategies. Does anyone have advice for a new Rails user (and new MVC user) on strategies to approach debugging. What path do you follow? Is there a generally accepted approach? Is there a way to step through the code?
Right now I am using unit testing as a kind of "lint" checker, but that only goes so far.
Although I want to solve it, the actual error I am getting right now is not the main thrust of this question.
(PS: The problem is not a duplicated "show" as documented in elsewhere on Stackoverflow
I haven't seen this mentioned yet but another option is to put a debugger statement in your code. Like this
def some_method
something = 3
debugger
# ... more code
end
If this is in a rails app when the code reaches debugger it will cause the terminal window running the web server to jump into something that looks like an irb session (I'm not exactly sure what it is). From there you can do puts something to see what the value is for example. You can even puts params to see what all the params values are. You can also step through the code, jump to a specific line, etc.
Pry seems to be a better way to go about this but it's how I used to debug before I knew about pry.
Note: You might need to do require 'ruby-debug' if you're doing this outside of rails.
i use a combination of irb, print statements, logging and pry bindings. (pry is a great gem)
irb is a great way to just play around with your ruby or rails app in the console. You could just enter the code from your controller (or similar) and see if it breaks in console for faster feedback loop. But remember you have to do reload! if you change anything in your class/module.
print statements are easy if you're running tests and just want it to output something a different points in your test. But if your testing in a browser I would recommend writing to the logger: Rails.logger.debug "...". But remember to set your logging level in your configuration to DEBUG -or- you can just do Rails.logger.info instead which should show up by default. Then you can just tail or view the logs in my_app/logs/development.rb.
My favorite method for really tricky bugs is that if the error is happening in a test you can just place binding.pry in the preceding line and then it will pause your test at that line and drop you into a console. I recommend watching the rails casts for more in-depth info: http://railscasts.com/episodes/280-pry-with-rails
I do not start Rails project without 'pry' gem.
Add gem to Genfile:
group :development, :test do
gem 'pry'
end
and stop request execution anywhere in your project, just put
binding.pry
to your model, controller, tests ..., or
<% binding.pry %>
in your view's, templates, partials.
Then you can check what ever you want objects, params, variables ...
Type exit to leave pry environment, and request will continue.
The Ruby on Rails Guide would be a great place to start, but there's plenty more.
I always have a rails console session or at minimum an irb session to play with to see if things do what I think they do.
I also use RubyMine which has an excellent integrated debugger http://www.jetbrains.com/ruby/
Beside pry gem, another option would be byebug. This gem enables you to temporarily stop code execution at a breakpoint, which is marked with keyword byebug inside the code. When execution reaches the breakpoint, a marker will be pointing to the current line, and you are able to type in commands.
This Gem offers a huge set of commands, the most commonly used ones are:
next - this command enables you to go to next line
step - goes into each invoked method step by step
break - it stops the execution of code
continue - continues code execution
This is a great article to check for debugging in rails.
In my main Sinatra controller, I want to debug the params hash after it is POSTed from a form.
I have added:
puts params.inspect
and
set :logging, :true
The params.inspect works if everything goes well. But if an error happens before the controller is executed I'm not getting any information about the error like I would in Rails by default.
What's the best way to get useful debug info?
This example did not work at all (the app wouldn't even start after I added this code):
configure do
Log = Logger.new("sinatra.log")
Log.level = Logger::INFO
end
followed by:
Log.info "#{#users.inspect}"
You could try adding a before filter that prints out the parameters
before do
puts '[Params]'
p params
end
My opinion is that for debug you should use configure :development do because some debugging flags are turned on in this scenario. So, under your configure do block you can enable the flags:
enable :logging, :dump_errors, :raise_errors
and for your logging facility:
log = File.new("sinatra.log", "a")
STDOUT.reopen(log)
STDERR.reopen(log)
From the Sinatra handbook:
dump_errors option controls whether the backtrace is dumped to rack.errors when an exception is raised from a route. The option is enabled by default for top-level apps.
raise_errors - allow exceptions to propagate outside of the app
(...)
The :raise_errors option is disabled by default for classic style apps and enabled by default for Sinatra::Base subclasses.
I also use the
puts "something" + myvar.inspect
method in the middle of my controllers.
As #jshen says, ruby-debug is a very nice tool - if you are using Ruby 1.8.
In order to use it in Sinatra, insert
require 'ruby-debug/debugger'
where you'd like debugging to start.
I recommend using Pry or the Ruby debugger. With Pry, you can use the command line to traverse your methods and variables like you would in bash.
See "How to use Pry with Sinatra?".
In order to find the best way to debug sinatra app, I created a repo at github. The most useful part is step into method debug, which looks like below.
Here is the repo: https://github.com/hlee/sinatra_debugger_example
I'd highly recommend using ruby-debug for Ruby 1.8. It's very easy to setup and use once you learn the four or five basic commands. It will allow you to set a breakpoint where you want to inspect the params and interactively play with it like you would in IRB.
Ruby Debuggers in Sinatra
You are free to use Ruby debuggers for Sinatra. The main issue is that you will need to know which Ruby Gem is used for which Ruby version. For most people now that means Ruby 2.X and byebug.
Ruby Debuggers by Ruby version
Ruby Version Gem Install require add breakpoint
---------------------------------------------------------------------
1.8.X ruby-debug 'ruby-debug/debugger' debugger
1.9.X debugger 'debugger' debugger
2.0.0+ byebug 'byebug' byebug
Once you know that you must install the gem, require it in your code and then add breakpoints by typing a keyword. Taking byebug as an example:
install: gem install byebug
require: require 'byebug'
breakpoint: byebug
Further Reading
Byebug project
Byebug guide to use a terminal debugger
Have you thought about trying something like this article: http://www.gittr.com/index.php/archive/logging-with-sinatra-and-passenger-another-try/
I'm guessing since you mentioned your main Sinatra controller, you have more than one, which means you're subclassing Sinatra::Base rather than using a classic (top-level) Sinatra app. If this is indeed the case, a lot of the default error-handling that Sinatra does is disabled by default.
If you include set :show_exceptions, true if development? in the class definition, you'll get friendly error pages that include a stack trace, params, etc, instead of just an internal server error. Another option is to set :raise_errors, false and then include a error do ... end block that will run whenever one of your routes raises an error.
I'd recommend using the debugger gem for Ruby 1.9.
To use this with your Sinatra app:
Add the gem to your Gemfile
gem "debugger"
Install the gem by running
bundle
In your main sinatra app file, add
require 'debugger'
Now to debug, you just have to add the following line
debugger
anywhere in your code.
When the code is being executed and debugger is seen, code would stop and you can inspect variables, run commands (using eval), etc.