Как Вы отлаживаете приложение Sinatra как приложение для направляющих?

Что-то другие комментарии опустило: если уже существует библиотека, которая делает то, что Вы хотите, она сохраняет Вас имеющий необходимость написать код .

Возможно Вы играете семантику здесь: мне "платформа журналирования" обычно немного больше, чем класс, который пишет сообщения журнала в файл... поэтому, что Вы сделали, запись Ваша собственная платформа журналирования. Учитывая, что Вы сделали так, существует, очевидно приблизительно точка в "использовании Платформы журналирования"!

В конечном счете Вы испытываете необходимость, чтобы удостовериться, что это обрабатывает параллельный вход правильно (блокирующий поток вывода), может зарегистрироваться в файл, системный журнал, и т.д., может сделать прокрутку журнала и так далее. Можно сохранить себя что усилие при помощи чужого хорошо протестированного кода.

31
задан nova 1 September 2009 в 21:34
поделиться

6 ответов

Вы можете попробовать добавить предварительный фильтр, который выводит параметры

before do
  puts '[Params]'
  p params
end
20
ответ дан 27 November 2019 в 22:05
поделиться

Вы не думали попробовать что-нибудь вроде этой статьи: http://www.gittr.com/index.php/archive/logging-with-sinatra-and-passenger-another -try /

1
ответ дан 27 November 2019 в 22:05
поделиться

Я считаю, что для отладки вы должны использовать configure : development do, потому что в этом сценарии включены некоторые флаги отладки. Итак, в блоке configure do вы можете включить флаги:

enable :logging, :dump_errors, :raise_errors

и для вашего средства ведения журнала:

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

Из справочника Sinatra:

  • dump_errors параметр контролирует, сбрасывается ли обратная трассировка в rack.errors , когда исключение возникает из маршрута. Этот параметр включен по умолчанию для приложений верхнего уровня.

  • raise_errors - разрешить исключениям распространяться за пределы приложения (...) Параметр : raise_errors отключен по умолчанию для приложений в классическом стиле и по умолчанию включен для подклассов Sinatra :: Base.

Я также использую метод

puts "something" + myvar.inspect

в середине своих контроллеров.

14
ответ дан 27 November 2019 в 22:05
поделиться

Я бы очень рекомендовал использовать ruby-debug для Ruby 1.8. Его очень легко настроить и использовать, как только вы выучите четыре или пять основных команд. Она позволит вам установить точку останова там, где вы хотите проверить параметры и интерактивно поиграть с ними, как в IRB.

3
ответ дан 27 November 2019 в 22:05
поделиться

Я предполагаю, что поскольку вы упомянули ваш главный контроллер Sinatra, у вас их несколько, что означает, что вы используете подклассы Sinatra::Base, а не классическое (верхнего уровня) приложение Sinatra. Если это действительно так, то многие стандартные средства обработки ошибок, которые Sinatra использует по умолчанию, по умолчанию отключены.

Если вы включите set :show_exceptions, true if development? в определение класса, вы получите дружественные страницы ошибок, включающие трассировку стека, параметры и т.д., вместо просто внутренней ошибки сервера. Другой вариант - установить :raise_errors, false и затем включить error do ... end блок, который будет выполняться всякий раз, когда один из ваших маршрутов вызывает ошибку.

1
ответ дан 27 November 2019 в 22:05
поделиться

Как говорит @jshen, ruby-debug - очень хороший инструмент, если вы используете Ruby 1.8.

Чтобы использовать его в Sinatra, вставьте

require 'ruby-debug/debugger' 

в то место, где вы хотите начать отладку.

10
ответ дан 27 November 2019 в 22:05
поделиться
Другие вопросы по тегам:

Похожие вопросы: