Когда использовать `save` против` save! `В модели?

Question

В соответствии с сохраните удар головой, активная запись сведет вас с ума , мы должны избегать использования save! и rescue идиомы для исключительных ситуаций. Учитывая это, скажем, модель должна @post.mark_rejected.

Если код в mark_rejected дает сбой из-за одной из следующих проблем, следует ли создать исключение? :

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

Если мы не выбрасываем исключение, то:

• действие контроллера должно было бы проверить возвращаемое значение mark_rejected и сделать это
• мы не ожидаем исключения из этого вызова метода, поэтому мы не пишем предложение rescue в действии контроллера, таким образом, исключение всплывает до (..wherever ..) и, вероятно, будет отображаться как некоторые ( 500 HTTP?) Ошибка

Пример кода:

def mark_rejected
  ...
  save!
end

или

def mark_rejected
  ...
  save
end

Answer 1

save! вызовет ошибку в случае неудачи.

save вернет логическое значение типа true или false.

Answer 2

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

Это меньше строккода, чтобы проверить, является ли возвращаемое значение ложным, чем спасти исключение, поэтому я не вижу, как это проблема с проверкой возвращаемого значения, если вы уже должны спасти исключение.Как часто исключение, выдаваемое save!, когда-либо будет накапливать стек вызовов на практике?Редко, если вообще когда-либо, по моему опыту.

Если при вызове save возникает исключение, а не save!, вы должны захотеть, чтобы на нем отображалась страница с ошибкой 500, потому что это то, что произошло: неисправимо,неизвестная, неожиданная внутренняя ошибка сервера.

Answer 3

Предложение: используйте save, когда оно находится на последней строке; save! в противном случае.

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