Oops, I think my description was somewhat misleading. I don't expect
`respond_to_arguments?` to check for lines in the method body that might
raise an `ArgumentError`. I expect it to check only whether the provided
list of arguments matches the method signature.

Maybe this example will clarify:

~~~ruby
class Foobar
  def self.hello(str)
    raise ArgumentError unless arg.is_a?(str)
  end
end

Foobar.respond_to_arguments?(:hello, "goodbye")  # => true
Foobar.respond_to_arguments?(:hello, 123)  # => true, because 123 matches
the method signature, even though the method will raise an ArgumentError
when you call it.
Foobar.respond_to_arguments?(:hello, "goodbye", "goodbye")  # => false,
because the method has only one parameter
~~~

El sb., 4 de nov. de 2017 a la(s) 11:49, <shevegen / gmail.com> escribi:

> Issue #14079 has been updated by shevegen (Robert A. Heiler).
>
>
> Hmm. Benoit, I may have misunderstood him but I think he was not
> asking for argument checks per se, but instead being able to
> know whether a method will respond with an ArgumentError beforehand
> (such as before calling a method).
>
> If that is the idea, and if I understood it, then I think this is
> an interesting idea. But I may have misunderstood.
>
> If I understood it correctly, then Nate sort of poses the question
> to ruby like in this manner:
>
> "Hello Ruby! I want to pass this data, such as the number 5, to
> that particular method. Please tell me beforehand whether this
> may lead to a problem such as ArgumentError."
>
> So if this is the case, then this is a bit the reverse way of
> the more known begin/rescue style:
>
>     begin
>       do_stuff
>     rescue TheSpecificError; end
>
> In one case, this will usually be defined within the method
> body; whereas I assume that in Nate's example, he'd want to
> be able to easily query this kind of behaviour beforehand
> altogether. But perhaps Nate can explain whether this is
> what he meant or not.
>
> The names are a bit verbose though; .respond_to_arguments_missing?
> for example.
>
> Anyway, I personally think the idea is ok if I understood Nate
> correctly. It's a bit like introspection, but doing so
> beforehand.
>
> ----------------------------------------
> Feature #14079: Validate argument list without calling method
> https://bugs.ruby-lang.org/issues/14079#change-67699
>
> * Author: nate00 (Nate Sullivan)
> * Status: Open
> * Priority: Normal
> * Assignee:
> * Target version:
> ----------------------------------------
> I would find it useful to check whether a list of arguments will cause an
> `ArgumentError` when passed to a method, but without calling that method.
>
> Maybe this method would be called `respond_to_arguments?`. Here's an
> example, where I check whether I can pass various argument lists to
> `String#prepend`:
>
> ~~~ruby
> str = "hello"
>
> # String#prepend accepts 1 argument, not 0 or 2:
> str.respond_to_arguments?(:prepend, "foo", "bar")   # => false
> str.respond_to_arguments?(:prepend, "foo")          # => true
> str.respond_to_arguments?(:prepend)                 # => false
>
> # Indeed, we get an ArgumentError if we pass 0 or 2 arguments:
> str.prepend("foo", "bar")   # raises ArgumentError
> str.prepend("foo")          # success!
> str.prepend                 # raises ArgumentError
> ~~~
>
> My use case is a background job processing system. It works like this: I
> call `MyWorker.perform_async` with some arguments; the arguments are
> serialized and put into a queue; and then a background worker takes those
> arguments from the queue, deserializes them and passes them to
> `MyWorker.perform`. If I passed invalid arguments, I don't know they were
> invalid until the background worker tries to call `perform`. But I'd like
> to know immediately when I call `perform_async`.
>
> Perhaps a `respond_to_arguments_missing?` method would be required also.
>
> Maybe `respond_to_arguments?` is a bad name. You could reasonably assume
> that it takes the same optional second parameter as `respond_to?` (i.e.,
> `include_all`), but my proposal doesn't support an optional second
> parameter.
>
> Thank you for your consideration!
>
>
>
> --
> https://bugs.ruby-lang.org/
>
> Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
>
(supressed text/html)
Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>