Name your exceptions and add enough data to debug it in the message

This is part of the Semicolon&Sons Code Diary - consisting of lessons learned on the job. You're in the exceptions category.

Last Updated: 2022-12-01

I opened up my error tracking tool (Rollbar) one day to see the following error report title:


This was not remotely helpful in helping me decide whether I should do something without going in and reading the code.

The triggering code was:

def populate(params)
  purchasable_type = params.fetch(:purchasable_type)
  # i.e. no exception name or message given
  raise unless PURCHASABLE_TYPES.include?(purchasable_type)

The same problem occurs to a slightly less extent with the more genericly named exceptions. i.e. This could be clearer:

raise ArgumentError

The key to improving is to add an informative message that includes specific information about the data in question that caused the error.

raise ArgumentError, "No law level known: #{law_level}"


raise "Error: Invalid purchasable type given: #{purchasable_type}" unless PURCHASABLE_TYPES.include?(purchasable_type)

The main advantages to this practice is that:


Give your exceptions custom names and include enough data to debug it in your DB or dashboard.