There is only one way to rollback a transaction in Rails: using an exception.
Although an exception may be used to rollback a transaction is OK in certain scenarios, i think it should not be used to rollback all of them. Making a nice differentiation between errors and exceptions makes the code more readable and easy to maintain (it looks awkward to write an exception to handle a name length validation that is not honored in order to rollback a transaction, when ther is already a .valid?
method related to the model that handle that)
Basically i think it would be nice to honor the next two rules:
-
“Exceptions are not meant to be expected, that is why they are called exceptions”
-
“Don’t use exceptions for control flow”
Some benefits:
-
We will not have two different ways to handle the same model-validation: so we can use
.valid?
and model’serrors
array to handle model validations within (or not) a transaction -
Good differentiation of what an error is (something that we expect to happen) and an exception (something that is not expected to happen) which is a perfect match for this proposed idea of having a proper
ActiveModel::Error
object which can be used within a transaction too, instead a Exception -
Error handling within a Transaction will easier to write and read, for example, something around this:
In the model…
class Model < ApplicationRecord
def some_method(…)
…
Transaction do
rollback unless user.save && invite.save
end
Althoug we roolbacked the transaction this gets executed because we
did not use an Exception, just regular model valiation
user, invite
…
end
end
In the controller
class SomeController < ApplicationController
def some_action
user, invite = Model.some_method(…)
If user && invite
All OK, render json etc
else
Something went wrong… render errors using ActiveRecord::Error related to user and/or invite models
end
…
end
end