Технически, первый вызывает RuntimeError с сообщением, установленным на "foo"
, а второй вызывает исключение с сообщением, установленным на "foo"
.
Практически, существует значительная разница между тем, когда выхотел бы использовать первое и когда вы хотите использовать второе.
Проще говоря, вы, вероятно, хотите RuntimeError
, а не Exception
.Спасательный блок без аргумента будет ловить RuntimeErrors
, но НЕ будет ловить Exception
s.Поэтому, если вы поднимете Exception
в своем коде, этот код не поймает его:
begin
rescue
end
Чтобы поймать Exception
, вам нужно будет сделать это:
begin
rescue Exception
end
Это означает, что в некотором смысле Exception
является «худшей» ошибкой, чем RuntimeError
, потому что вам нужно проделать больше работы для ее восстановления.
То, что вы хотите, зависит от того, какВаш проект обрабатывает ошибки.Например, в наших демонах основной цикл имеет пустое спасение, которое поймает RuntimeErrors
, сообщит о них и затем продолжит.Но в одном или двух обстоятельствах мы хотим, чтобы демон действительно умирал от ошибки, и в этом случае мы поднимаем Exception
, который проходит через наш «нормальный код обработки ошибок» и выходит.
И снова, если вы пишете код библиотеки, вам, вероятно, понадобится RuntimeError
, а не Exception
, так как пользователи вашей библиотеки будут удивлены, если возникнут ошибки, которые не может перехватить пустой блок rescue
, и онПонадобится мгновение, чтобы понять, почему.
Наконец, я должен сказать, что RuntimeError
является подклассом класса StandardError
, и фактическое правило таково, что хотя вы можете raise
При любом типе объекта пустой rescue
по умолчанию будет перехватывать только то, что наследуется от StandardError
.Все остальное должно быть конкретным.