Question

Is there a way of doing the old “on error resume next” routine in ruby?

I’ve got array of value filled in dynamically from elsewhere (read from MQTT topics to be precise) then I want to do a bunch of numeric calculations on them and publish the results. The values SHOULD be numeric but are possibly missing or non-numeric.

At the moment my code looks something like

values=[]


//values get loaded here 

begin
  Publish('topic1',value[0]*10+value[1])
rescue TypeError,NoMethodError,ZeroDivisionError
end

begin
  Publish('topic2',value[3]/value[4])
rescue TypeError,NoMethodError,ZeroDivisionError
end

//etc etc

If the calculation fails for any reason the program should just skip that step and go on.

It works but surely theres a better way than all those identical begin..rescue blocks? Ruby is about “DRY” after all..

Is there a way of re-writing the above so that a single begin..rescue construct is used while still allowing all calculations to be attempted?

UPDATED

How safe to do something like

def safe_Publish(topic,value)
  return if value.nil?
  Publish(topic,value)
end

and call with
safe_Publish(‘topic2’,(value[3]/value[4] rescue nil))

The main problem is that the above catches ALL exceptions not just the ones I’m expecting which makes me a little nervous.

Answer 1

The on error resume next coding style is really dangerous – as it makes finding new bugs you accidentally introduce to your program very hard to find. Instead, I would just write a different version of publish that doesn’t throw those exceptions:

def try_publish(topic_name)
  begin
    Publish('topic1',yield)
  rescue TypeError,NoMethodError,ZeroDivisionError
    # are you sure you don't want to do anything here? Even logging the errors
    # somewhere could be useful.
  end
end

You can then call this with:

try_publish('topic1') { value[0]*10+value[1] }

If TypeError,NoMethodError or ZeroDivisionError are thrown by the expression, they will be caught and ignored.

Now your original method won’t require any rescues.

---

If you really wanted an on error resume next, you could possibly do it by monkey patching the raise method in Kernel, but that would be a horrible idea.