Вызов остановки в sinatra не устанавливает sinatra.error

Question

Мой пример использования: я хотел бы заняться обработкой ошибок в sinatra.Для этого я настраиваю обработчик ошибок следующим образом

error 0..600 do
  @@logger.error("error reason #{env['sinatra.error']}")
end

Переменная sinatra.error устанавливается нормально, если ошибка была вызвана явным повышением исключения

get '/' do
  raise "Fail the request"
end 

Но если остановкаиспользуется для завершения запроса, тогда sinatra.error не устанавливается.Рассматривая код sinatra, это выглядит так, как ожидалось, потому что throwing: halt заставляет поток управления идти вверх, вызывая и таким образом обходя установку переменной sinatra.error.

Мой вопрос заключается в том, как использовать обработчик ошибок вместе с остановкой, чтобы я мог получить причину ошибки в обработчике ошибок.

Answer 1

Я думаю, что поведение, которое вы видите, связано с намеченной целью halt. Когда вы звоните, вы не обязательно сигнализируете по ошибке; вы просто хотите, чтобы выполнение было немедленно остановлено, что может быть особенно полезно в фильтре. Если вы проверяете README Синатры, он говорит, что вы используете halt для «немедленной остановки запроса в рамках использования фильтра или маршрута». Конечно, вы обычно делаете это из-за ошибки.

Интересно также отметить, что определенный вами обработчик ошибок вызывается не только при возникновении ошибок, но и при обработке обычных запросов, в том числе со статусом 200. И в этих случаях env[sinatra.error] не будет установлен либо.

Что вы можете сделать в обработчике ошибок, это проверить исключение и, если оно недоступно, проверить код ответа. Например (обратите внимание, что это классическое приложение):

error 0..600 do
  boom = @env['sinatra.error']
  status = response.status
  case
  when boom != nil
    puts 'exception: ' + boom
  when status != 200
    puts 'error: ' + status
  end
end

Одним из следствий этого является то, что в этом обработчике обычные запросы неотличимы от тех, которые прерываются halt, поскольку оба генерируют код состояния 200. Однако, если вы используете halt для сообщения об ошибках, тогда вы должны использовать код ошибки, например, 500.