lailsonbm/matching_exceptions

#matches returning the matching occurrences

tiagofsilva opened this issue · 5 comments

I was wondering if #matches shouldn't actually be #matches?, since it returns a boolean. But then it hit me that it makes sense to return occurrences of the match instead of a boolean. What do you guys think?

gvc commented

I think that it depends on the behavior of rescue ME.matches("foo") => e. What would be assigned to e? I think that it should always be the exception, no?

In the regular ruby workflow, yes, I think. But since we are matching the error message inside the error object (and assigning the message, not the error, to variable e), we could do a little more work to assign to a Match object that would contain the original error and the matches. Or something like that. My point being: what was your plan when choosing the name matches for the method? To return a boolean, the error itself or it wasn't designed to assign anything?

But since we are matching the error message inside the error object (and assigning the message, not the error, to variable e)

We're assigning e to the error, though:

begin
  raise StandardError.new("error message")
rescue ME.matches("message") => e
  require 'byebug'
  byebug
end

# ...

(byebug) e.class
StandardError
(byebug) puts e.backtrace
/home/lbrito/work/guava/matching_exceptions/spec/matching_exceptions_spec.rb:21:in `block (2 levels) in <top (required)>'
/home/lbrito/.rvm/gems/ruby-2.3.3/gems/rspec-core-3.6.0/lib/rspec/core/example.rb:254:in `instance_exec'
/home/lbrito/.rvm/gems/ruby-2.3.3/gems/rspec-core-3.6.0/lib/rspec/core/example.rb:254:in `block in run'
/home/lbrito/.rvm/gems/ruby-2.3.3/gems/rspec-core-3.6.0/lib/rspec/core/example.rb:500:in `block in with_around_and_singleton_context_hooks'
...

Oops! My mistake, then. I must've have forgotten to ask for the class of the object to my debugger, cos when I printed it just showed "error message", and I simply trusted it was a string =/.
I still have a problem with the possibility of matching more than one occurrence since rescue always catching the first one... but I think that's another issue. Thanks!

We should have a test to guarantee that it always assigns to the error caught then.