method_missing and respond_to?

Analogy categoryAnalogies

When Ruby can't find a method for a given message send, it doesn't immediately raise NoMethodError — first it calls a special hook method named method_missing on the receiver, passing the method name (as a symbol) and any arguments. Every object inherits a default method_missing from BasicObject that simply raises NoMethodError, but overriding it lets you intercept arbitrary method calls and handle them dynamically. This is the mechanism behind dynamic finders, flexible configuration objects, proxy/delegator objects, and DSLs that appear to support an open-ended vocabulary of method names.

🏏

Cricket analogy: method_missing catching an unrecognized call before raising an error is like a fielding captain intercepting an unfamiliar signal from the boundary and deciding how to react, instead of the umpire immediately calling it dead ball.

Intercepting calls with method_missing

A method_missing override receives the missing method's name as its first argument, followed by any positional arguments, keyword arguments, and a block, mirroring a normal method signature but with the method name prepended. Inside, you typically pattern-match on the name (often via a regex or a known prefix/suffix) and either handle it or call super to fall back to the default NoMethodError-raising behavior for anything you don't recognize.

🏏

Cricket analogy: A method_missing override receiving the method name first, like inspecting the ball delivered before deciding a shot, and calling super to fall back is like leaving an unplayable delivery to the wicketkeeper rather than attempting a risky shot yourself.

ruby

class DynamicConfig
  def initialize(settings = {})
    @settings = settings
  end

  def method_missing(name, *args, &block)
    key = name.to_s

    if key.end_with?("=")
      @settings[key.chomp("=").to_sym] = args.first
    elsif @settings.key?(key.to_sym)
      @settings[key.to_sym]
    else
      super
    end
  end
end

config = DynamicConfig.new(timeout: 30)
config.timeout        #=> 30
config.retries = 5
config.retries         #=> 5
config.nonexistent     #=> raises NoMethodError via super

Forgetting to call super for unhandled cases is one of the most common method_missing bugs: it causes the method to silently return nil for any typo or unsupported call, instead of raising a clear NoMethodError — turning what should be a loud, early failure into a confusing bug discovered much later.

Pairing with respond_to_missing?

Overriding method_missing alone creates a subtle inconsistency: the object will happily respond to config.timeout, but config.respond_to?(:timeout) still returns false, because respond_to? has no idea method_missing intercepts that call. This breaks any code that checks respond_to? before calling a method (a common defensive pattern), and it breaks introspection tools, method(:name), and duck-typing checks. The fix is to also override respond_to_missing?, which respond_to? consults internally, and which should return true for exactly the same names method_missing would handle.

🏏

Cricket analogy: A batter who can improvise any shot but whose official technique rating (respond_to?) still says 'cannot play a reverse sweep' is a mismatch, just like config.respond_to?(:timeout) returning false even though config.timeout actually works via method_missing.

ruby

class DynamicConfig
  def respond_to_missing?(name, include_private = false)
    key = name.to_s.chomp("=").to_sym
    @settings.key?(key) || name.to_s.end_with?("=") || super
  end
end

config = DynamicConfig.new(timeout: 30)
config.respond_to?(:timeout)     #=> true
config.respond_to?(:nonexistent) #=> false (falls through to super)

In many modern codebases, method_missing has been partially superseded by define_method called in a loop at class-definition time (defining real methods up front) or by Ruby's Module#define_method combined with metaprogramming — these approaches are often preferred because real, defined methods are faster (no fallback dispatch), show up correctly in respond_to?, and appear in stack traces and IDE autocomplete without any extra work.

method_missing is invoked automatically when no matching method is found for a call, receiving the method name plus arguments.
Always call super for names you don't recognize inside method_missing, so real typos still raise NoMethodError.
respond_to_missing? must mirror method_missing's logic so respond_to? reports accurate results for intercepted calls.
Failing to define respond_to_missing? breaks respond_to?, method(:name), and any code relying on accurate introspection.
method_missing enables dynamic finders, proxies, and DSLs, but adds a small per-call dispatch overhead compared to real methods.
define_method-based metaprogramming is often a faster, more introspectable alternative when the set of method names is known in advance.