Error messages and display in Ruby on Rails - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

How does Rails display validation errors in a form?

Given a Rails form with a model that has validation errors, how does the form_with helper display these errors by default?

A It logs the errors to the server console but does not display anything on the form.

B It highlights the input fields with errors but does not show any error messages.

C It redirects the user to a separate error page showing all validation errors.

D It automatically adds a <code>div</code> with <code>id='error_explanation'</code> containing a list of error messages above the form.

💡 Hint

Think about what Rails helpers do automatically when validations fail.

Rails form_with automatically generates a div with id='error_explanation' that lists all validation errors above the form fields, making it easy for users to see what went wrong.

📝 Syntax

intermediate

Correct syntax to display error messages for a specific attribute

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

A <%= @user.errors.full_messages_for(:email).join(", ") %>

B <%= @user.errors[:email].full_messages.join(", ") %>

C <%= @user.errors.messages_for(:email).join(", ") %>

D <%= @user.errors.get_messages(:email).join(", ") %>

💡 Hint

Look for the method that returns full error messages for a specific attribute.

The method full_messages_for(:attribute) returns an array of full error messages for that attribute. The other options either use incorrect method names or call methods on wrong objects.

🔧 Debug

advanced

Why are error messages not showing in the form?

A developer notices that after submitting a form with invalid data, the error messages are not displayed, even though validations fail. The form uses form_with model: @user. What is the most likely cause?

A The form uses <code>form_tag</code> instead of <code>form_with</code>.

B The model does not have any validations defined.

C The controller action does not re-render the form view on validation failure, but redirects instead.

D The database schema does not have the required columns.

💡 Hint

Think about what happens after a failed save in the controller.

If the controller redirects after a failed save, the error messages stored in the model instance are lost. To display errors, the controller should re-render the form view with the invalid model instance.

❓ state_output

advanced

What is the content of flash[:error] after a failed save?

In a Rails controller, after if @user.save fails, the developer sets flash[:error] = @user.errors.full_messages.join(", "). What will flash[:error] contain?

A A hash of attribute names and error messages.

B A single string with all error messages joined by commas.

C An array of error messages.

D An empty string because errors are not saved in flash.

💡 Hint

Consider what join does to an array.

The full_messages method returns an array of strings. Using join(", ") converts this array into a single string with messages separated by commas.

🧠 Conceptual

expert

Why use errors.add in custom validation methods?

In Rails, when writing a custom validation method inside a model, why do we use errors.add(:attribute, "message") instead of just raising an exception?

A Because <code>errors.add</code> collects errors to show in the form without stopping execution, while raising an exception halts the process.

B Because raising exceptions is deprecated in Rails validations.

C Because <code>errors.add</code> automatically fixes the invalid data.

D Because raising exceptions only works in controllers, not models.

💡 Hint

Think about user experience and how validations should behave.

Using errors.add allows Rails to collect all validation errors and display them to the user without stopping the program. Raising exceptions would interrupt the normal flow and is not suitable for validations.

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