Question

According to save bang your head, active record will drive you mad, we should avoid using save! and rescue idiom for exceptional situations. Given that, say a model needs to @post.mark_rejected.

If the code in mark_rejected fails due to one of the below problems, should an exception be thrown? :

• if there is a validation problem
• if a non-nullable-field was being assigned a null
• if there was a connection loss to database

If we do not throw an exception, then:

• controller action would have to check for return value of mark_rejected and do it’s thing
• we are not expecting an exception from that method call, so we do not write a rescue clause in the controller action, thus the exception bubbles up to (..wherever..) and will probably show up as some (500 HTTP?) error

Example code:

def mark_rejected
  ...
  save!
end

or

def mark_rejected
  ...
  save
end

Answer 1

There’s more overhead in an exception, so there is a performance issue, especially when it can be expected that it will likely be thrown often, as is the case with save.

It is fewer lines of code to check if the return value is false than rescue an exception, so I don’t see how it’s a problem having to check for the return value if you already have to rescue the exception. How often would an exception thrown by save! ever have to bubble-up the call stack in practice? Rarely, if ever, in my experience.

If there is an exception thrown when calling save as opposed to save! you should want it to show a 500 error page because that’s what happened: an unrecoverable, unknown, unexpected internal server error.