ruby on rails - tutorial - ¿Cómo depuras una aplicación de Sinatra como una aplicación de Rails?

ruby on rails que es

Question

En mi controlador principal de Sinatra, quiero depurar el hash params después de que se publique desde un formulario.

Yo he añadido:

puts params.inspect

y

set :logging, :true

El params.inspect funciona si todo va bien. Pero si ocurre un error antes de que se ejecute el controlador, no obtengo ninguna información sobre el error como lo haría en Rails de forma predeterminada.

¿Cuál es la mejor manera de obtener información útil de depuración?

Este ejemplo no funcionó en absoluto (la aplicación ni siquiera se iniciaría después de agregar este código):

configure do 
  Log = Logger.new("sinatra.log")
  Log.level  = Logger::INFO 
end

seguido por:

Log.info "#{@users.inspect}"

Answer 1

¿Has pensado en probar algo como este artículo? http://www.gittr.com/index.php/archive/logging-with-sinatra-and-passenger-another-try/

Answer 2

Como dice @jshen, ruby-debug es una herramienta muy buena.

Para usarlo en Sinatra, inserte

require ''ruby-debug/debugger'' 

donde te gustaría comenzar la depuración.

Answer 3

Mi opinión es que para la depuración debe usar configure :development do porque en este escenario están activadas algunas marcas de depuración. Por lo tanto, bajo su bloque de configure do puede habilitar los indicadores:

enable :logging, :dump_errors, :raise_errors

y para su instalación de registro:

log = File.new("sinatra.log", "a")
STDOUT.reopen(log)
STDERR.reopen(log)

Del manual de Sinatra:

• dump_errors opción dump_errors controla si el retroceso se vuelca en rack.errors cuando se rack.errors una excepción desde una ruta. La opción está habilitada de forma predeterminada para las aplicaciones de nivel superior.

• raise_errors : permite que las excepciones se propaguen fuera de la aplicación (...) La opción :raise_errors está deshabilitada de forma predeterminada para aplicaciones de estilo clásico y habilitada de forma predeterminada para las subclases Sinatra :: Base.

Yo tambien uso el

puts "something" + myvar.inspect

Método en medio de mis controladores.

Answer 4

Para encontrar la mejor manera de depurar la aplicación sinatra, creé un repositorio en github. La parte más útil es el paso a la depuración del método, que se ve a continuación.

Aquí está el repositorio: https://github.com/hlee/sinatra_debugger_example

Answer 5

Puedes intentar agregar un filtro anterior que imprima los parámetros

before do
  puts ''[Params]''
  p params
end

Answer 6

Recomiendo encarecidamente usar ruby-debug. Es muy fácil de configurar y usar una vez que aprenda los cuatro o cinco comandos básicos. Te permitirá establecer un punto de interrupción en el que quieras inspeccionar los parámetros y jugar de forma interactiva con ellos como lo harías en IRB.

Answer 7

Recomiendo usar Pry o el depurador de Ruby. Con Pry, puedes usar la línea de comando para atravesar tus métodos y variables como lo harías en bash.

Consulte " ¿Cómo usar Pry con Sinatra? ".

Answer 8

Recomiendo usar la gema debugger .

Para usar esto con tu aplicación Sinatra:

1. Agrega la gema a tu Gemfile

   gem "debugger"

2. Instala la gema corriendo

   bundle

3. En su archivo principal de la aplicación sinatra, agregue

   require ''debugger''

4. Ahora para depurar, solo tienes que agregar la siguiente línea

   debugger

   En cualquier parte de tu código.

Cuando se ejecuta el código y se ve el debugger , el código se detiene y puede inspeccionar variables, ejecutar comandos (usando eval ), etc.

Answer 9

Supongo que desde que mencionaste tu controlador principal de Sinatra, tienes más de uno, lo que significa que estás subclasificando Sinatra :: Base en lugar de usar una aplicación clásica (nivel superior) de Sinatra. Si este es el caso, gran parte del manejo de errores predeterminado que realiza Sinatra está deshabilitado de forma predeterminada.

Si incluye set :show_exceptions, true if development? en la definición de clase, obtendrá páginas de error amigables que incluyen un seguimiento de pila, parámetros, etc., en lugar de solo un error interno del servidor. Otra opción es set :raise_errors, false y luego incluir un error do ... end block que se ejecutará cada vez que una de sus rutas genere un error.