Ruby on Rails
Debugging

Debugging Rails Application

Het is erg belangrijk om een toepassing te debuggen om de stroom van de logica en gegevens van een toepassing te begrijpen. Het helpt logische bugs op te lossen en voegt waarde toe aan de programmeerervaring en codekwaliteit. Twee populaire edelstenen voor foutopsporing zijn debugger (voor ruby 1.9.2 en 1.9.3) en byebug (voor ruby> = 2.x).

.rb volgt te werk om .rb bestanden te debuggen:

1. Voeg debugger of byebug aan de development van Gemfile
2. Voer bundle install
3. Voeg debugger of byebug als breekpunt
4. Voer de code uit of doe een verzoek
5. Zie het rails-serverlogboek gestopt bij het opgegeven breekpunt
6. Op dit punt kunt u uw serverterminal net als rails console en de waarden van variabele en params controleren
7. Typ next en druk op enter om naar de volgende instructie te enter
8. Typ c en druk op enter uit te stappen

Als u .html.erb bestanden wilt debuggen, wordt het breekpunt toegevoegd als <% debugger %>

Foutopsporing in uw IDE

Elke goede IDE biedt een GUI voor interactief debuggen van Ruby (en dus Rails) -applicaties waar u breekpunten, horloges, automatisch pauzeren bij uitzondering kunt toevoegen en waarmee u de code-uitvoering zelfs stap voor stap, regel voor regel kunt volgen.

Bekijk bijvoorbeeld een van de beste Ruby IDE's, RubyMine's foutopsporingsfuncties op de foto

Ruby on Rails debuggen + advies voor beginners

Het debuggen door het verhogen van uitzonderingen is veel eenvoudiger dan turen door middel van print log statements, en voor de meeste bugs, zijn over het algemeen veel sneller dan het openstellen van een IRB-debugger zoals pry of byebug . Die hulpmiddelen zouden niet je eerste stap moeten zijn.

Ruby / Rails snel debuggen:

1. Snelle methode: .inspect vervolgens een Exception en .inspect het resultaat

De snelste manier om te debuggen Ruby (vooral Rails) code is te raise een uitzondering langs de uitvoering pad van uw code tijdens het bellen .inspect op de methode of object (bijvoorbeeld foo ):

raise foo.inspect

In de bovenstaande code .inspect raise een Exception die de uitvoering van uw code stopt en een foutbericht retourneert dat handig .inspect bevat over het object / de methode (bijv. foo ) op de regel die u probeert te debuggen.

Deze techniek is handig voor het snel onderzoeken van een object of methode ( bijv. Is het nil ? ) En om meteen te bevestigen of een coderegel überhaupt binnen een bepaalde context wordt uitgevoerd.

2. Fallback: gebruik een robijnrode IRB- debugger zoals byebug of pry

Pas nadat u informatie hebt over de status van de uitvoering van uw codes, zou u moeten overwegen om naar een robijnrode edelsteen irb debugger zoals pry of byebug waar u dieper kunt ingaan op de status van objecten binnen uw uitvoeringspad.

De byebug edelsteen gebruiken voor foutopsporing in Rails:

1. Voeg gem 'byebug' binnen de ontwikkelingsgroep in je Gemfile
2. Voer bundle install
3. Plaats vervolgens de uitdrukking byebug in het uitvoeringspad van de code die u wilt onderzoeken.

Deze byebug variabele zal bij uitvoering een robijnrode IRB-sessie van uw code openen, waardoor u direct toegang hebt tot de status van objecten zoals deze zich op dat moment in de uitvoering van de code bevinden.

IRB-foutopsporingen zoals Byebug zijn handig voor het grondig analyseren van de status van uw code tijdens de uitvoering. Ze zijn echter meer tijdrovend in vergelijking met het verhogen van fouten, dus in de meeste situaties zouden ze niet uw eerste stap moeten zijn.

Algemeen advies voor beginners

Wanneer u een probleem probeert te debuggen, is het een goed advies om altijd: Lees de! @ # $ Ing Foutmelding (RTFM)

Dat betekent foutmeldingen zorgvuldig en volledig lezen voordat u handelt, zodat u begrijpt wat het u probeert te vertellen. Wanneer u fouten opspoort, stelt u de volgende mentale vragen in deze volgorde bij het lezen van een foutbericht:

1. Naar welke klasse verwijst de fout? (dwz heb ik de juiste objectklasse of is mijn object nil ? )
2. Naar welke methode verwijst de fout? (dwz is hun een type in de methode; kan ik deze methode op dit type / deze klasse van objecten aanroepen? )
3. Ten slotte, met behulp van wat ik kan afleiden uit mijn laatste twee vragen, welke regels code moet ik onderzoeken? (vergeet niet: de laatste regel code in de stacktracering is niet noodzakelijk waar het probleem ligt.)

Let in het stapeltraject vooral op coderegels die afkomstig zijn van uw project (bijv. Lijnen die beginnen met de app/... als u Rails gebruikt). 99% van de tijd is het probleem met uw eigen code.

Om te illustreren waarom tolken in deze volgorde belangrijk is ...

Bijvoorbeeld een Ruby-foutmelding die veel beginners in verwarring brengt:

U voert code uit die op een gegeven moment als zodanig wordt uitgevoerd:

@foo = Foo.new

...

@foo.bar

en je krijgt een foutmelding die zegt:

undefined method "bar" for Nil:nilClass

Beginners zien deze fout en denk dat het probleem is dat de methode bar is niet gedefinieerd. Het is niet. In deze fout is het echte deel dat ertoe doet:

for Nil:nilClass

for Nil:nilClass betekent dat @foo nul is! @foo is geen Foo instantievariabele! Je hebt een object dat Nil . Wanneer u deze fout ziet, het is gewoon robijn probeert te vertellen dat de methode bar bestaat niet voor objecten van de klasse Nil . (nou duh! want we proberen een methode te gebruiken voor een object van de klasse Foo niet Nil ).

Helaas, vanwege de manier waarop deze fout is geschreven ( undefined method "bar" for Nil:nilClass ), is het gemakkelijk om te undefined method "bar" for Nil:nilClass dat deze fout te maken heeft met het feit dat bar undefined . Als hij niet zorgvuldig te lezen deze fout zorgt ervoor dat beginners ten onrechte te gaan graven in de details van de bar methode op Foo , volledig ontbreekt het deel van de fout die hints dat het voorwerp is van de verkeerde klasse (in dit geval: nihil). Het is een fout die gemakkelijk kan worden vermeden door foutmeldingen in hun geheel te lezen.

Samenvatting:

Lees altijd het hele foutbericht zorgvuldig voordat u begint met foutopsporing. Dat betekent: Controleer altijd de klasse type van een object in een foutmelding eerst, dan haar methoden, voordat u begint met het speuren in elk stacktrace of regel code waar je denkt dat de fout kan worden voorkomen. Die 5 seconden kunnen je 5 uur frustratie besparen.

tl; dr: niet lui kijken naar afdruklogboeken: in plaats daarvan uitzonderingen opwerpen. Vermijd konijnenholten door fouten zorgvuldig te lezen voordat u fouten opspoort.

Debuggen ruby-on-rails applicatie met koevoet

wrikken is een krachtig hulpmiddel dat kan worden gebruikt om elke ruby-toepassing te debuggen. Het opzetten van een ruby-on-rails-applicatie met dit juweeltje is heel eenvoudig en eenvoudig.

Opstelling

Beginnen met het opsporen van fouten in uw toepassing met peuteren

• Voeg gem 'pry' aan de Gemfile van de applicatie en bundel het

group :development, :test do
  gem 'pry'
end

• Navigeer naar de hoofdmap van de toepassing op de terminalconsole en voer de bundle install . U bent er helemaal klaar voor om het overal in uw applicatie te gebruiken.

Gebruik

Het gebruik van koevoet in uw toepassing omvat alleen binding.pry op de breekpunten die u wilt inspecteren tijdens het debuggen. U kunt overal in uw toepassing binding.pry breekpunten toevoegen die worden geïnterpreteerd door ruby interpreter (elke app / controllers, app / modellen, app / views-bestanden)

i) Debuggen van een controller

app / controllers / users_controller.rb

class UsersController < ApplicationController
  def show
    use_id = params[:id]
    // breakpoint to inspect if the action is receiving param as expected
    binding.pry
    @user = User.find(user_id)
    respond_to do |format|
      format.html
    end
  end
end

In dit voorbeeld is de rails server pauzes met een koevoet console op het break-point wanneer u probeert om een pagina routing te bezoeken show actie UsersController . U kunt vanaf dat breekpunt het params object inspecteren en een ActiveRecord-query uitvoeren op het User

ii) Een weergave debuggen

app / views / users / show.html.haml

%table
  %tbody
    %tr
      %td ID
      %td= @user.id
    %tr
      %td email
      %td= @user.email
    %tr
      %td logged in ?          
      %td
        - binding.pry
        - if @user.logged_in?
          %p= "Logged in"
        - else
          %p= "Logged out"

In dit voorbeeld pauzeert het breekpunt met koevoetconsole wanneer de users/show pagina vooraf is gecompileerd in de rails-server voordat deze wordt teruggestuurd naar de browser van de client. Dit breekpunt maakt het mogelijk om de correctheid van @user.logged_in? te debuggen @user.logged_in? wanneer het zich misdraagt.

ii) Een model debuggen

app/models/user.rb

class User < ActiveRecord::Base    
  def full_name
    binding.pry
    "#{self.first_name} #{self.last_name}"
  end      
end

In dit voorbeeld kan het break-point worden gebruikt om te debuggen User model instantie methode full_name wanneer deze methode wordt aangeroepen vanuit overal in de applicatie.

Concluderend, wrikken is een krachtig hulpmiddel voor foutopsporing voor railtoepassingen met eenvoudige installatie en eenvoudige foutopsporingsrichtlijn. Probeer dit eens.