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: 2021-05-16

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

RuntimeError

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)
end

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}"

or

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

The main advantages to this practice is that:

Lesson

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