Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NoSuchMethodError object produces confusing error messages #13471

Closed
DartBot opened this issue Sep 21, 2013 · 5 comments
Closed

NoSuchMethodError object produces confusing error messages #13471

DartBot opened this issue Sep 21, 2013 · 5 comments
Assignees
Labels
area-library core-a library-core type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)

Comments

@DartBot
Copy link

DartBot commented Sep 21, 2013

This issue was originally filed by @mhausner


Assume function foo defined like this:

foo(a,{b}) => print("ha");

And a call to foo like this

foo(10,20)

This produces a NoSuchMethodError that claims that an incorrect number of arguments was passed to foo:

The VM says:

Unhandled exception:
No top-level method 'foo' with matching arguments declared.

NoSuchMethodError: incorrect number of arguments passed to method named 'foo'
Receiver: top-level
Tried calling: foo(10, 20)
Found: foo(a, b)

Dart2js says:

out.js:430: NoSuchMethodError: incorrect number of arguments passed to method named 'Symbol("foo")'
Receiver: ""
Tried calling: Symbol("foo")(10, 20)
Found: Symbol("foo")(a, b)
  throw H.wrapException(new P.NoSuchMethodError(obj, new H.Symbol0($name), $ar

The error message is confusing. It says that foo was called with two arguments, and that we found a foo with two arguments, but the error is "wrong number of arguments"....

The problem is that in the "Found" call target, we can't express the actual signature of foo. The NoSuchMethodError object takes a list of names for the parameters of the function we found, but no info about positional, optional and named arguments.

NoSuchMethodError(Object receiver,
                    Symbol memberName,
                    List positionalArguments,
                    Map<Symbol ,dynamic> namedArguments,
                    [List existingArgumentNames = null]) <<<==== names of arguments of function

Instead of a list of argument names, the NoSuchMethodError object should instead take a String describing the signature of the existing function. Or it should not define that part in the public API and leave it to the implementation to handle it.

@DartBot
Copy link
Author

DartBot commented Sep 21, 2013

This comment was originally written by @mhausner


cc @iposva-google.
cc @mhausner.
cc @gbracha.

@lrhn
Copy link
Member

lrhn commented Sep 23, 2013

I agree that the NoSuchMethodError constructor should not expose anything non-necessary. It's easy to add private constructors that the implementations can use instead, so they shouldn't be public.

We can consider removing the implementation entirely, and letting it all be internal.
I believe the spec does refer to constructing a new NoSuchMethodError using a constructor call with four arguments, so we might need that. On the other hand, it's probably a case of over-specification. The implementations can should be able to create a subclass of NoSuchMethodError if they prefer it.

The case where a user might want to use NoSuchMethodError is insider a noSuchMethod method, but they should be encouraged to just call super.noSuchMethod instead.

@lrhn
Copy link
Member

lrhn commented May 5, 2014

Added Library-Core label.

@gbracha
Copy link
Contributor

gbracha commented May 5, 2014

The language spec refers to invoking noSuchMethod with an argument of type Invocation, with the known properties of that type. It does not discuss how NoSuchMethodErrors are created, only that they are thrown. These are all public types and we cannot hide them even if we wanted to. You could add constructors to NoSuchMethodError if you found that helpful.

@kevmoo kevmoo added type-bug Incorrect behavior (everything from a crash to more subtle misbehavior) and removed priority-unassigned labels Feb 29, 2016
@lrhn lrhn added the core-a label Aug 11, 2017
@crelier crelier self-assigned this Sep 18, 2017
@crelier
Copy link
Contributor

crelier commented Sep 27, 2017

The reported issue has been fixed a long time ago.
A more recent change (https://dart-review.googlesource.com/c/sdk/+/5329) is addressing the further concerns about constructing a NosuchMethodError.

@crelier crelier closed this as completed Sep 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-library core-a library-core type-bug Incorrect behavior (everything from a crash to more subtle misbehavior)
Projects
None yet
Development

No branches or pull requests

5 participants