Какова лучшая практика в обработке странных исключений в Rails?

Question

скажем, у меня есть эта функция в Rails (на самом деле я: P - eval используется, потому что в будущем будет третий, четвертый или более номер_класса):

    def all_profession_costs(class_number)
        second = {'Wealth Ranger' => 1000, 'Wisdom Vacuum' => 1000, 'Life Leecher' => 1000, 'Dense Mass' => 1000}
        costs = eval(class_number)
        costs
    end 

Это кажетсятеперь будет работать нормально, но если я случайно использую 'firsta' для своего class_number, все это, скорее всего, рухнет, и, возможно, возникнет трудная ошибка.

Итак, теперь я думаю о двух вещах.Я определенно хочу как можно больше проверять вещи, но мне не нравится помещать такие вещи, как «поднимать RuntimeError», потому что это делает код намного уродливее.И заставляет его работать медленнее.Ну, я полагаю, что последнее терпимо, так как проверка означает лучший код.

Однако я не люблю безобразно.Я подумываю о создании отдельного модуля ExceptionHandling для того, чтобы выполнять подобные проверки.

В этом примере я бы хотел проверить, является ли class_number 'first', 'second' или 'third'.

Вместо чего-то вроде:

raise RuntimeError unless ['first', 'second', 'third'].include?(class_number.to_s)

Может быть, я мог бы написать простой модуль (работающий, вероятно, как декоратор Python), который сделает эту вещь лучше для чтения, что я думаю большекрасивый код, что-то вроде:

validates class_number, :inclusion => ['first', 'second', 'third']

Вроде как стандартный валидатор модели.

Что вы думаете об этом?Это хорошая идея или нет?Как бы вы относились к обработке ошибок в Rails?

Answer 1

Проверка - В приведенном вами примере у вас нет , чтобы вызвать исключение. Вы можете просто вернуть false, если class_number не является одним из «first», «second», «third». И проверьте ответ, где метод вызывается. Этот подход является подходом валидации.

Исключение - Вы вызываете исключения, когда ошибка, которая может быть причиной, вызвана не неправильным вводом данных пользователем, а тем, что что-то серьезно пошло не так в вашей логике, реализации или факторах, которые вы не можете контролировать.

Это не жесткие и быстрые правила. Это скорее руководство, которому я обычно следую.

В приведенном выше примере это зависит от того, откуда исходит class_number. Это из пользовательского ввода? Я бы сделал проверку. Если это не должно исходить от пользовательского ввода, я бы поднял исключение. Кроме того, вам не нужно просто поднять RuntimeError. Вы можете создать свой собственный класс исключений. В вашем случае что-то вроде

class InvalidClassNumber < RuntimeError
end

и делай разве что ['first', 'second', 'third']. include? (class_number.to_s) поднять InvalidClassNumber: «Номер класса может быть« первым »,« вторым »или« третьим ». Мы получили # {class_number.to_s}» конец

Когда вы вызываете этот метод, вы можете спасти его и сделать все, что вам нужно для его обработки.

begin
  @profession = @user.profession(class_number)
rescue InvalidClassNumber => e
  # Do whatever you need to
  logger.debug e.message
  # redirect somewhere, or whatever
end

Пользовательские классы исключений дают вам возможность обрабатывать именно те исключения, которые вы ожидаете, вместо обработки универсального исключения, такого как RuntimeError. В вашем приложении может быть столько классов исключений, сколько вам нужно. Вы даже можете дать им пространство имен, используя ::. Profession::InvalidClassNumber < RuntimeError.