Ruby Обработка ошибок, помимо основ

 (Thread.current[:errors] ||= []) << 'Any error message goes here' 

Thread.current[:errors] как переменная доступна в любом месте вашего кода (обычно я использую переменные с глобальной областью действия, за редкими исключениями, подобными этой. Думайте об этой переменной как о очень простом глобальном обработчике ошибок.) Технически, поток -local переменные имеют область видимости потока, которая должна быть бессмысленной, если вы не пишете многопоточный код. Если вы это сделаете, знайте, что имя переменной говорит само за себя; это локально для потока (thread = ваша программа, если вы не работаете с несколькими потоками).

Вы можете использовать вышеприведенное выражение в любом месте вашего кода, из любого метода.

Чтобы избежать повторения кода, я Thread.current выражение Thread.current в отдельный метод (убедитесь, что метод доступен из любой точки вашего кода):

 def report_error(error_message) (Thread.current[:errors] ||= []) << "#{error_message}" end 

Допустим, у нас есть some_random_method который вылетает, и мы хотим some_random_method детали:

 def some_random_method begin raise 'an error!' rescue => error report_error("#{error.class} and #{error.message}") end end some_random_method p Thread.current[:errors] #=> ["RuntimeError and an error!"] 

На данный момент ошибки хранятся в локальных переменных потока. Мы хотим сохранить их в файле. Давайте напишем метод log_errors , который сделает это:

 def log_errors File.open('errors.txt', 'a') do |file| (Thread.current[:errors] ||= []).each do |error| file.puts error end end end 

Однако этого недостаточно. Мы хотим, чтобы этот метод выполнялся при выходе из программы, и не имеет значения, завершится ли он с ошибкой или без нее. Как мы видели ранее, это довольно легко сделать: просто поместите вызов метода в at_exit :

 at_exit { log_errors } 

Будьте осторожны с вашим спасательным кодом

Трудный путь, который я усвоил, заключается в том, что вы никогда не будете слишком осторожны с кодом, который вы отправили в rescue . Что делать, если код внутри него дает сбой и создает исключение? Конечно, вы можете вкладывать средства rescue , но это противоречит всей цели заявления!

Представьте, была ли ваша программа ответственна, скажем, за строительство здания. Затем происходит пожар. В ответ на это на помощь приходит пожарный:

 begin # building the building rescue Fire Fireman.dispatch end 

Мы хотим убедиться, что пожарный отлично справляется со своей задачей. Мы не хотим, чтобы он загорелся из-за неисправного оборудования! Кроме того, мы не хотим, чтобы автомобиль пожарного сломался по дороге к зданию. Мы хотим, чтобы все было безупречно, в том числе 0% отказов. Это должно быть конечной целью с вашим кодом внутри оператора rescue . Как я уже говорил, вы можете пойти глубже и найти кого-то, чтобы спасти спасателя, что может привести к проблемам.

Никогда не спасайте Exception , никогда не спасайте широко

Прочитав 2 или 3 статьи об основах обработки исключений в Ruby, вы обязательно увидите совет никогда не спасать Exception . Exception является корнем библиотеки классов исключений, «матерью всех исключений». Я хочу пойти еще дальше с этим советом и рекомендовать вам никогда не спасать в целом. Это включает в себя игнорирование широких классов, таких как StandardError (сам StandardError имеет более 300 дочерних классов, происходящих от него). Таким образом, спасая StandardError , вы обрабатываете 300 потенциальных сбоев. Теперь скажите мне, если у вас есть спасательный блок, обрабатывающий 300 возможных случаев отказа, какова вероятность того, что rescue блок сам выйдет из строя? Представьте себе, что вы предоставляете пожарному такое же оборудование для работы с одноэтажными домами и 100-этажным зданием! Не хорошая идея.

Итак, каково решение? Вместо того, чтобы разбираться в общих чертах, попытайтесь спасти определенные ошибки (которые не имеют исключений более 100 детей). Что приводит меня к моей следующей точке …

Типы исключений (по вероятности случившегося)

Многие люди проповедуют такие вещи, как «исключения должны быть исключительными», не понимая, что слово «исключительные» часто неправильно понимают. Я предлагаю лучший способ классификации конкретного исключения по вероятности того, что оно действительно произойдет:

• Возможно случиться. Это то, что многие люди имеют в виду, когда говорят, что исключение должно быть «исключительным». Исключение, которое может произойти в ситуации, далекой от того, что вы можете ожидать.
• Вероятно, случится . Вы можете с достаточной точностью предсказать, что в некоторых ситуациях это исключение в конечном итоге произойдет.
• Должно (обязательно) произойти Исключение произойдет, и вы можете легко создать ситуацию для этого.

Давайте сначала рассмотрим третий (последний) тип. Если ваше исключение требуется или имеет очень высокую вероятность возникновения, подумайте еще раз, если вам вообще нужно его повысить. Если вы повышаете, вы используете это исключение для потока управления? Это плохая идея. Например, возникновение исключения, если пользователь ввел неправильный ввод вместо повторного запроса (с использованием некоторого типа цикла). Если вы спасаете исключение, которое часто происходит и возникает в какой-то библиотеке, посмотрите, сможете ли вы обернуть всю логику в какой-то метод проверки, в котором вы получите возвращаемое значение вместо постоянного сбоя.

 def some_method(some_argument, error_strategy = method(:raise)) raise "#{some_argument}" rescue error_strategy.call end some_method(1) # '1' (RuntimeError) 

 error_handler = Proc.new { puts 'I rescued it!' } some_method(1, error_handler) 

 def method_that_should_return_an_array this_method_call_will_raise_an_error('some argument') rescue [] # your method will return this end 

 some_method_that_might_return_nil || raise 'nil returned' 

 my_value = some_method_that_might_raise_nil if my_value.nil? # do something else # do something else end