Cacher is the code snippet organizer for pro developers

Active Record and validation failure

A prototypical Action Controller action using Active Record will:

• call save (the safe version of save!) on the model
• if sucessful
• redirect or render some view
• if unsuccessful
• render a different view
• presume that the model contains error information that, when presented to the user, can be corrected

def create
    @resource = Resource.new(resource_params)
    
    if @resource.save
      render json: @resource, status: 201
    else
      render json: @resource, status: 400
    end
  end

Failing to succeed means, specifically, that the validations failed, or the callback chain was halted. In the case of a call to save!, ActiveRecord::RecordNotSaved or ActiveRecord::RecordInvalid are 'unexceptional' exceptions to be expected and handled.

Developers are required to differentiate between exceptions that are expected and exceptions that are truly exceptional. This differentiation can add difficulty when designing their own classes and model logic.

An alternate flow

In the case of an HTTP API that is intrinsically resourceful, we could alter this flow and avoid this distinction without loss of functionality or ease of use. For a resourceful JSON API, in both cases of 'expected' failure, a client still expects a JSON response about the requested resource, including information about why the request could not be satisfied.

In a more loosely coupled paradigm, the ActiveRecord callback chain has been replaced by Interaction classes responsible for the interactions on and between models. The validation coordination has been moved to Mapper classes. In both classes, an exception indicating the record could not be mutated as requested could be raised. This exception acts as an indicator that the requested resource mutation is not valid is some way (and shouldn't be retried without modification).

def create
  @resource = Resource.new(resource_params)
  ResourceMapper.create(@resource)
    
  render json: @resource, status: 201
rescue RecordInvalid
  render json: @resource, status: 400
end

or

rescue_from RecordInvalid, with: :render_bad_resource

def create
  @resource = Resource.new(resource_params)
  ResourceMapper.create(@resource)
    
  render json: @resource, status: 201
end

private

def render_bad_resource
  render json: @resource, status: 400
end

The logic and behavior haven't been altered, but there is no intrinsic differentiation between 'exceptional' exceptions and 'expected' ones.

Practical implications

• Mapper methods raise if not successful, return excepted resourdce if successful
• Interaction methods raise if not successful, return true if successful
• Asyncronous method invocation need not worry about an alternate exception paradigm that silently traps errors