Prasanna Natarajan - Caller-supplied Fallback Strategy

I’m reading the exceptional Avdi Grimm’s Exceptional Ruby book. (Thanks Cass!)

Like Avdi and Ruby, the book is also exceptional!

One section of the book is “Your Failure handling Strategy”. It has a handful of advices, one of which is this: Caller-supplied fallback strategy.

Last week at work, I stumbled upon a problem. Within minutes I had the solution too. I wrote test cases, wrote the solution code and pushed and closed the story when tests were green.

But it felt wrong to me. I wasn’t convinced of my solution. I knew there had to be a better way, but I couldn’t come up with an elegant replacement.

Until now, after reading this chapter in the book.

First, the problem, and the original solution I had conceived.

Problem statement

I want all the ineffective cats of a user. (Don’t ask me what I’m going to do with them).

User has many cats.

A Cat is effective when it has both teeth and claws (or nails?).

A Cat is ineffective when it has only one of these 2.

For the sake of the example, assume that humans are fair people and don’t consider a cat ineffective if it doesn’t have both.

It’s a fair comparison right? If you compare a weaponless cat with a weaponised cat, then you are a… catist! Don’t be a catist, be a fair human. OK?

So here’s the cat.rb:

def effective?
  if teeth && claws
    return true
  elsif teeth or claws
    return false
  else
    fail "You Catist!"
  end
end

My Design rationale: the cat.effective? method can only return true or false. Anything else it is asked to do that it doesn’t know, it just gives up by raising an exception.

And at user.rb, I collect all ineffective cats like so:

def ineffective_cats
  self.cats.reject do |cat|
    cat.effective? rescue true
  end
end

That line with rescue true is what made me uncomfortable. I had to add it because that’s the only way the cats with neither weapons will not be included in the ineffective_cats list.

Enter Exceptional Ruby

One of the gems from the book is this:

Exceptions shouldn’t be expected. Use exceptions only for exceptional situations.It is hardly exceptional to fail to open a file.

When writing an application you expect invalid input from users. Since we expect invalid input we should NOT be handling it via exceptions because exceptions should only be used for un-expected situations.

Light-bulb moment! So a cat with no weapons is totally expected inside of the cat.effective? method! It’s not an abnormality. It’s not an exception. It’s just a different part of the rule.

So, what can be returned in the place of the fail line? The truth obviously. If you ask a weaponless cat if it is effective or not, it can’t say true or false. Technically it can only say ‘nothing’, aka nil.

So, cat.rb becomes:

def effective?
  if teeth && claws
    return true
  elsif teeth or claws
    return false
  else
    nil # NOTE
  end
end

Now, another gem from the book:

In most cases, the caller should determine how to handle an error, not the callee.

So it’s now obvious that the caller has to decide what to do if one of the cats returned nil when asked if effective.

Well, for your usecase, we can simply ignore the cat that returned nil from the final list of ineffective cats. Like so:

# user.rb
def ineffective_cats
  self.cats.reject do |cat|
    result = cat.effective?
    (result.nil? || result) ? true : false
  end
end

This can be expressed more succintly as:

def ineffective_cats
  self.cats.reject do |cat|
    cat.effective? or true
  end
end

This appears to be only slightly better than our initial version where we used recue true. But we have deliberately used 2 of the approaches described earlier here from the book:

For the case of a weaponless cat, instead of raising an exception, we are returning nil. A weaponless cat is not unexpected in that method, so no need for exceptions
We have let the caller decide what to do with the nil return value. Our caller had various options: It could have raised hell, it could have logged a warning saying there’s a weaponless cat in the system, or it could have sneakily send it along with the weaponised cats. But our caller chose to simply ignore the weaponless cats, because it should!

This post still doesn’t use “caller supplied fallback strategy” in its proper form. I’ll do it here:

# cat.rb
def effective?(failure_policy=method(:raise))
  if teeth && claws
    return true
  elsif teeth or claws
    return false
  else
    fail "You Catist! This cat has no weapons, you can't consider it weaponsgrade!"
  end
rescue => e
  # we are 'punting' the decision to act on the exception up to the caller.
  failure_policy.call(e.message)
end

# user.rb
def ineffective_cats
  failure_policy = ->(exception) do # NOTICE: we don't do anything with the exception
    warn "A weaponless cat found. Just thought you should know."
    true
  end
  self.cats.reject do |cat|
    cat.effective?(failure_policy)
  end
end

This is “Caller supplied fallback strategy” in a nutshell.