Common Ruby Runtime Errors

Direct Answer

Common Ruby runtime errors name the violated operation: NoMethodError means the receiver does not provide the called method, NameError means Ruby could not resolve a local variable or constant, ArgumentError usually means the arguments do not match the method contract, TypeError means an operation received an incompatible kind of object, and KeyError reports a required missing hash key. ZeroDivisionError covers integer division by zero, while application code often raises a specific StandardError subclass for domain failures. Read the exception class, message, and first relevant application frame together; do not hide the cause with a broad rescue or automatic safe navigation.

Deep Dive & Architecture

Ruby raises an exception when execution cannot continue under the operation's contract. The class groups similar failures, the message supplies instance-specific details, and the backtrace records the active call chain. Diagnosing only from the class is too broad: two NoMethodError instances can come from a nil association, a typo, a private method call, or an object of an unexpected class.

Method and name failures are related but distinct. NoMethodError is raised after Ruby has a receiver but cannot complete the method call in that context. NameError is raised when a name such as a constant cannot be found through its lookup rules. A missing Rails constant may be a naming or autoload-path problem, while an undefined local can simply be a branch that never assigned it.

Argument errors describe the call boundary. Ruby checks positional and keyword requirements before entering many methods, producing details about given and expected arguments. A method can also raise ArgumentError for a value whose form is unacceptable. TypeError is reserved for incompatible object types or conversions; application validation should not depend on forcing every bad user input into that built-in category.

Collection access communicates optionality. hash[:role] returns nil when the key is missing, which is suitable for optional data but can defer the failure. hash.fetch(:role) raises KeyError at the missing requirement. An array's ordinary index access returns nil outside its range, while array.fetch(index) raises IndexError. Choosing the strict form can move a bug closer to the boundary that violated the expectation.

The repair should match the domain rule. If a customer may be absent, model and display that state. If every paid order must have a customer, validate or constrain it when the order enters that state. Adding &. everywhere turns both situations into nil and makes corrupted required data harder to notice. Broad rescue StandardError has a similar masking effect unless the layer records and re-raises or converts a known failure deliberately.

Custom exceptions make recovery boundaries readable. A payment adapter might translate one provider timeout into PaymentUnavailable, preserving the original cause, because the caller can schedule a retry. It should not translate a NoMethodError from its own bug into the same recoverable outcome. Specific categories, helpful messages without secrets, and intact backtraces give tests and operators evidence rather than generic failure text.

Code Example

def recipient_email(payload)
  customer = payload.fetch(:customer) # KeyError if required data is absent
  email = customer.fetch(:email)
  raise ArgumentError, 'email must be a String' unless email.is_a?(String)

  email
end

puts recipient_email(customer: { email: 'ada@example.com' })

# Safe navigation is different: use it only when absence is valid.
optional_email = { customer: nil }[:customer]&.fetch(:email)
p optional_email # nil

Common Mistakes & Pitfalls

Ignoring the error message (it names the method and receiver — read it), or not checking for nil before calling a method.