Introduction

When an RSpec example says "wrong number of arguments" while you are testing an exception, the bug is usually not in raise_error itself. The failure normally comes from how the code under test is being called, how the custom exception is initialized, or how the expectation block is written. The fastest way to debug it is to separate "what method is being invoked" from "what exception do I expect."

Use raise_error with a Block

The correct RSpec shape is:

1RSpec.describe "division" do
2  it "raises an ArgumentError for zero divisor" do
3    expect { 10 / 0 }.to raise_error(ZeroDivisionError)
4  end
5end

The important detail is the block around the code that should raise. Without the block, RSpec evaluates the code too early and the failure can surface in confusing ways.

Incorrect:

expect(my_method(1, 2)).to raise_error(ArgumentError)

Correct:

expect { my_method(1, 2) }.to raise_error(ArgumentError)

That one mistake accounts for a large share of exception-testing errors in RSpec.

Distinguish Method Arity from Exception Assertions

Suppose the real code is:

1def greet(name)
2  raise ArgumentError, "name required" if name.nil?
3  "hello #{name}"
4end

This spec is valid:

1RSpec.describe "#greet" do
2  it "raises for nil name" do
3    expect { greet(nil) }.to raise_error(ArgumentError, "name required")
4  end
5end

But this spec will produce a wrong-arguments failure before raise_error can even match:

expect { greet }.to raise_error(ArgumentError)

The method greet itself requires one argument. The error is about your call site, not about the RSpec matcher.

That is why the first debugging question should be: "Does the code inside the expectation block call the method with the right arity?"

Be Careful with Custom Exception Classes

Another common source of confusion is a custom exception class whose initializer expects different arguments than the code or test provides.

1class ApiError < StandardError
2  attr_reader :status
3
4  def initialize(message, status)
5    super(message)
6    @status = status
7  end
8end

Code under test:

def fetch!
  raise ApiError.new("request failed", 503)
end

Spec:

1RSpec.describe "#fetch!" do
2  it "raises ApiError" do
3    expect { fetch! }.to raise_error(ApiError, "request failed")
4  end
5end

This works because the block triggers the real method, and the matcher only checks class and message.

But if your production code does this:

raise ApiError.new("request failed")

you will get a wrong-number-of-arguments failure from ApiError#initialize, not from RSpec. That distinction matters when reading the traceback.

Match the Exception Message Only When It Helps

When debugging arity issues, simplify the matcher first:

expect { fetch! }.to raise_error(ApiError)

Once the basic exception class matches, add message checks:

expect { fetch! }.to raise_error(ApiError, /request failed/)

This helps you avoid chasing two problems at once. If the spec is already failing on the wrong exception class or wrong invocation, message assertions only add noise.

Read the Failure Location Carefully

The stack trace tells you whether the wrong-arguments error comes from:

• the method under test
• the custom exception initializer
• a helper invoked inside the block

That is the practical debugging flow:

1. confirm the expectation uses a block
2. confirm the method under test is called with correct arguments
3. confirm any custom error constructor is called with correct arguments
4. only then refine the matcher with message checks

Most of the time, step two or step three reveals the bug immediately.

Common Pitfalls

• Writing expect(method_call).to raise_error(...) instead of wrapping the call in a block.
• Testing an exception path while accidentally calling the method with the wrong number of arguments.
• Defining a custom exception initializer that requires arguments and then raising it incorrectly.
• Adding message matching too early and obscuring a more basic arity problem.
• Assuming every "wrong number of arguments" failure is an RSpec matcher problem instead of checking the traceback source.

Summary

• 'raise_error should wrap the code under test in expect { ... }.'
• A wrong-arguments failure usually comes from the invoked method or custom exception initializer, not from RSpec itself.
• Simplify the matcher to class-only checks while debugging.
• Read the traceback to find whether the arity issue is in the method call or the raise statement.
• Once the invocation is correct, add message assertions for stronger tests.