Как определить обработчик возврата rescue_from? - PullRequest
2 голосов
/ 14 октября 2019

У меня есть модуль обработчика исключений, который я включаю в свой контроллер, чтобы перехватывать все виды ошибок Rails:

module ExceptionHandler
  # provides the more graceful `included` method
  extend ActiveSupport::Concern

  included do
    rescue_from ActiveRecord::RecordNotFound do |e|
      render json: { message: e.message }, status: :not_found
      logger.error(e.message)
    end

    rescue_from ActionController::ParameterMissing do |e|
      logger.error(e.message)
      render json: {
        message: "Parameter missing",
        details: e.message,
        parameter: e.param
      }, status: :bad_request
    end

    rescue_from ActiveRecord::RecordInvalid do |e|
      logger.error(e.message)
      render json: {
        attributes: e.record.errors.messages.keys,
        message: "Invalid record",
        details: e.record.errors.messages,
      }, status: :unprocessable_entity
    end

    rescue_from ActionController::RoutingError do |e|
      logger.error(e.message)
      render json: { message: e.message }, status: :not_found
    end
  end
end

Однако, это ловит только определенные ошибки, которые я определил. Когда я сталкиваюсь с какой-то другой ошибкой, я получаю ответ JSON от Rails с довольно подробными сообщениями, трассировкой стека и т. Д.

Я хочу предотвратить это, по крайней мере в рабочей среде, и возвращаю только ошибку 500 с моимсобственный формат.

Я прочитал подобных сообщений , но они не содержат опций "отступления" для стандартных ошибок. Поэтому я попытался наивно добавить rescue_from StandardError, но это, кажется, имеет приоритет перед всеми другими ошибками, которые я определил.

Я думаю, я мог бы спасти StandardError и затем переключить регистр, но это кажетсякак хак:

  included do
    rescue_from StandardError do |e|
      # TPDP_ better öpggomg
      logger.error(e.message)
      handle_error(e)
    end
  end

Как правильно с этим бороться?

...