Error messages and display in Ruby on Rails - Step-by-Step Execution

Concept Flow - Error messages and display

User submits form

↓

Controller receives data

↓

Model validates data

↓

Save data

↓

Redirect or render success

↓

User sees error messages on form

This flow shows how Rails handles form submission, validates data, and displays error messages back to the user if needed.

Execution Sample

Ruby on Rails

class User < ApplicationRecord
  validates :email, presence: true
end

# In controller
if @user.save
  redirect_to root_path
else
  render :new
end

This code validates that email is present before saving a user; if validation fails, it re-renders the form to show errors.

Execution Table

Step	Action	Validation Result	Controller Decision	View Rendered	Error Messages Displayed
1	User submits form with email=''	Email presence validation fails	Render :new (form) again	Form with errors	Email can't be blank
2	User submits form with email='[e-mail]'	Validation passes	Redirect to root_path	Success page	No errors

💡 Execution stops after redirect or rendering form with errors based on validation result

Variable Tracker

Variable	Start	After Step 1	After Step 2
@user.email	nil	'' (empty string)	'[e-mail]'
@user.errors.full_messages	[]	["Email can't be blank"]	[]

Key Moments - 2 Insights

Why does the form re-render with errors instead of redirecting when validation fails?

Because in the execution_table row 1, validation fails and the controller chooses to render the form again to show errors instead of redirecting.

How are error messages accessed to display on the form?

Error messages are collected in @user.errors.full_messages as shown in variable_tracker after step 1, then displayed in the view.

Visual Quiz - 3 Questions

Look at the execution_table, what does the controller do when validation fails?

A Save the user anyway

B Redirect to root_path

C Render the form again with errors

D Raise an exception

💡 Hint

See execution_table row 1 under Controller Decision and View Rendered columns

According to variable_tracker, what is the value of @user.errors.full_messages after step 2?

A []

B ["Email can't be blank"]

C nil

D ['Invalid email']

💡 Hint

Check variable_tracker row for @user.errors.full_messages after step 2

If the user submits the form with a valid email, what will happen according to execution_table?

A Form re-renders with error messages

B User is redirected to root_path

C Validation fails

D Error messages are shown

💡 Hint

Look at execution_table row 2 under Validation Result and Controller Decision

Concept Snapshot

Rails error messages flow:
- User submits form
- Model validates data
- If errors, controller renders form with @model.errors
- Errors shown in view with full_messages
- If no errors, save and redirect
Use 'validates' in model and check 'save' result in controller.

Full Transcript

In Rails, when a user submits a form, the controller receives the data and tries to save the model. The model runs validations like checking if email is present. If validation fails, the controller renders the form again, passing error messages collected in @model.errors. The view displays these errors so the user knows what to fix. If validation passes, the controller redirects to a success page. This flow helps users correct mistakes easily by showing clear error messages on the form.

Practice

1. In Rails, which method provides a list of user-friendly error messages for a model's validation errors?

easy

A. @model.errors.count

B. @model.errors.details

C. @model.errors.keys

D. @model.errors.full_messages

Solution

1. Step 1: Understand error message methods

   @model.errors.full_messages returns an array of readable error strings, while others return metadata or counts.

2. Step 2: Identify user-friendly output

   Only full_messages gives clear, complete error messages suitable for display.

3. Final Answer:

   @model.errors.full_messages -> Option D

4. Quick Check:

   Error messages = full_messages [OK]

Hint: Use full_messages for readable error text [OK]

Common Mistakes:

• Using errors.details which gives error codes, not messages
• Using errors.keys which lists fields, not messages
• Using errors.count which returns number, not messages

2. Which of the following is the correct way to display error messages for a @user model in a Rails view?

easy

A. <%= @user.errors.full_messages.each do |msg| %> <%= msg %> <% end %>

B. <% @user.errors.full_messages.each do |msg| %> <%= msg %> <% end %>

C. <%= @user.errors.full_messages.map { |msg| content_tag(:p, msg) } %>

D. <% @user.errors.full_messages.map { |msg| content_tag(:p, msg) } %>

Solution

1. Step 1: Understand ERB tags for iteration

   <% %> runs Ruby code without output; <%= %> outputs the result. For loops, use <% %>.

2. Step 2: Identify correct syntax for displaying messages

   <% @user.errors.full_messages.each do |msg| %>

   <%= msg %>

   <% end %> correctly uses <% %> to loop and <%= %> inside to output each message.

3. Final Answer:

   Option B -> Option B

4. Quick Check:

   Loop with <% %>, output with <%= %> [OK]

Hint: Use <% %> for loops, <%= %> for output inside loops [OK]

Common Mistakes:

• Using <%= %> for loops causing unwanted output
• Using map without outputting results
• Mixing output and code tags incorrectly

3. Given this Rails code in a view:

<ul>
  <% @post.errors.full_messages.each do |msg| %>
    <li><%= msg %></li>
  <% end %>
</ul>

What will be the output if @post.errors.full_messages contains ["Title can't be blank", "Content is too short"]?

medium

A. Title can't be blankContent is too short

B. Title can't be blankContent is too short

C. Title can't be blankContent is too short

D. No output because of syntax error

Solution

1. Step 1: Understand the loop output

   The code loops over each error message and wraps it in
2. tags inside a <ul>.

3. Step 2: Match output to HTML structure

   The output will be a <ul> list with two
4. items showing each error message.

5. Final Answer:

   <ul><li>Title can't be blank</li><li>Content is too short</li></ul> -> Option A

6. Quick Check:

   Loop creates list items inside ul [OK]

Hint: Errors inside <li> tags within <ul> show as list [OK]

Common Mistakes:

• Forgetting <ul> tags causing invalid HTML
• Not using <li> tags for each message
• Confusing output with plain text

4. You wrote this code to display errors:

<%= @article.errors.full_messages.each do |msg| %>
  <p><%= msg %></p>
<% end %>

But no errors show up in the browser. What is the problem?

medium

A. The <code><p>s

B. You must call to_s on each message before displaying

C. Using <code><%= %>s

D. The errors array is empty, so nothing shows

Solution

1. Step 1: Check ERB tag usage for loops

   Using <%= %>each, which is the original array, not the loop content.

2. Step 2: Correct loop tag usage

   Use <% %> for loops to run code without output, then use <%= %> inside for each message.

3. Final Answer:

   Using <%= %> for the loop causes output of the array, not the messages -> Option C

4. Quick Check:

   Use <% %> for loops, not <%= %> [OK]

Hint: Use <% %> for loops, <%= %> for output inside loops [OK]

Common Mistakes:

• Using <%= %> for loops causing wrong output
• Assuming errors are empty without checking
• Misunderstanding HTML tag usage inside loops

5. You want to display error messages only if there are any errors on the @comment model. Which is the best way to do this in a Rails view?

hard

A. <% if @comment.errors.any? %>
<div role='alert' aria-live='assertive'>
<ul>
<% @comment.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>
<% end %>

B. <div>
<ul>
<% @comment.errors.full_messages.each do |msg| %>
<li><%= msg %></li>
<% end %>
</ul>
</div>

C. <% if @comment.errors.count > 0 %>
<p>Errors found</p>
<% end %>

D. <% unless @comment.errors.empty? %>
<p>Please fix errors</p>
<% end %>

Solution

1. Step 1: Check for errors presence

   Use errors.any? to check if there are any errors to display.

2. Step 2: Display errors accessibly

   Wrap errors in a div with role='alert' and aria-live='assertive' for screen readers to announce changes.

3. Step 3: Loop and show messages

   Use full_messages inside a ul with li for each error message.

4. Final Answer:

   Option A -> Option A

5. Quick Check:

   Check errors.any? and use accessible alert div [OK]

Hint: Use errors.any? and role='alert' div for accessible errors [OK]

Common Mistakes:

• Not checking if errors exist before displaying
• Missing accessibility roles for error containers
• Displaying generic messages without details