Альтернатива спасению в Ruby?

Question

Кажется, что в моем коде везде есть begin ... rescue ... end операторы! Это не похоже на то, что нужно делать.

Кто-нибудь может подсказать, как я могу поймать любые исключения, не помещая все в begin ... rescue ... end? Есть ли какой-нибудь способ просто сказать Руби заткнуться и продолжать идти, даже если возникло исключение?

Answer 1

Как и в других языках, для любой нетривиальной программы вам действительно нужна продуманная архитектура для обработки исключений. Один из подходов состоит в том, чтобы определить области обработки исключений в вашем проекте, и тогда вы, как правило, хотите перехватывать (спасать) исключения на границах области действия. Здесь есть компромисс. Чем ближе вы находитесь в стеке к месту возникновения исключения, тем больше у вас контекстной информации об условии, которое его вызвало. Если вы пытаетесь быть слишком детальным, вы сталкиваетесь с проблемами, которые вы описали. С другой стороны, если вы перехватываете исключения только в верхней части стека (в «main»), тогда контекст отсутствует. Таким образом, определение областей обработки исключений включает оценку этого компромисса по отношению к вашей конкретной программе или системе.

Ruby дает нам возможность «повторить попытку» - недоступно на некоторых других языках. Это следует использовать экономно! Но там, где это имеет смысл (например, ожидание освобождения сети или ресурса), такие исключения должны обрабатываться очень локально.

В противном случае, я склонен определять области исключений на довольно крупном уровне в большом проекте. Часто полезно собирать некоторую контекстную информацию, так как исключение всплывает от точки возникновения до различных границ области действия исключения. Чтобы помочь с этим, вы можете расширить иерархию классов исключений Ruby, определив некоторые из ваших собственных типов исключений для конкретного приложения, но опять же есть компромиссы. Ваш проект должен иметь четкие стандарты о том, когда использовать настраиваемые типы исключений по сравнению со сбором контекстных данных в поле сообщения, какую информацию должно содержать поле сообщения и т. Д., А также стратегию каталогизации сообщений, которые может генерировать ваш код.

В большинстве случаев исключения могут быть разрешены распространяться вверх к централизованному обработчику, регистрироваться (для технической группы и поддержки), генерировать полезные сообщения об ошибках для пользователя и определять, является ли условие достаточно серьезным, чтобы требует вашей программы для выхода. Как правило, все исключения должны обрабатываться в вашем коде или в используемой вами среде приложения. Не должно быть никаких исключений при переходе к обработке исключений по умолчанию для среды выполнения языка или ОС.

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

Answer 2

def action
    yield
    rescue
        ....
    ensure
        ....
end

action { stuff_goes_here }

Answer 3

Одна вещь, которая может заставить его выглядеть немного чище, - это спасение в конце метода, так что вам не нужно начинать и другой уровень отступа:

def get_file_prompt
  print "Enter file name: "
  return File.open(read)
rescue StandardError
  puts "File could not be opened"
  return nil
end

Answer 4

Ну нет.Весь смысл исключений состоит в том, что они являются условиями, которые должны быть обработаны.

Подумайте об этом так: Исключения - ваши друзья! Без них вам пришлось бы писать множество скучных условий.заявления, которые было бы трудно прочитать и поддерживать.

Если вы изучаете Ruby (или любой язык с системой исключений), работа с исключениями является одним из наиболее важных аспектов, и вам стоит потратитьвремя, чтобы понять, как с ними обращаться, когда их поднять, и когда их можно игнорировать.