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 should give access to the receiver and the data that would be in an invocation mirror. #6252

Closed
lrhn opened this issue Oct 25, 2012 · 5 comments
Labels
area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. closed-obsolete Closed as the reported issue is no longer relevant core-n P3 A lower priority bug or feature request type-enhancement A request for a change that isn't a bug

Comments

@lrhn
Copy link
Member

lrhn commented Oct 25, 2012

Currently NoSuchMethodError gives a somewhat useful error message, and it will probably get even better.
That risks people parsing the string message to get information.
To give a better experience, we could make the receiver, the methodName, what kind of call it was (getter/setter/method) and the actual arguments passed (i.e., the receiver and the data on a corresponding InvocationMirror).

We should also consider whether that would be a security problem by possibly revealing internal objects through an error message (CC turnidge).

@justinfagnani
Copy link
Contributor

Knowing the receiver is necessary if you want to differentiate between a NSME on an object that you're invoking a method on and an uncaught NSME originating from somewhere further down in the call stack. Polymer and Angular bindings would like to make such a distinction.

@floitschG
Copy link
Contributor

cc @kasperl.

@kasperl
Copy link

kasperl commented Oct 17, 2013

I'd prefer not to try to use the 'receiver' for figuring out where a NSME originates from. It's not a good model for it as it easily breaks down.

I've been toying with the notion of not having noSuchMethod actually do the throwing, but instead have a method on the invocation to do that for us.

   class Object {
     noSuchMethod(invocation) => invocation.notifyAbsent();
   }

   class MyClass {
     noSuchMethod(invocation) {
       if (invocation.memberName....) ...
       return super.noSuchMethod(invocation);
     }
   }

That allows us to pass in an invocation that doesn't throw in case of an absent property (something not handled by the noSuchMethod implementation), which is useful for implementing the reflective "ifAbsent" handling correctly:

   reflect(obj).getField(#foo, ifAbsent: () => 42 + 87)

@kasperl
Copy link

kasperl commented Oct 17, 2013

Small correction. The Invocation.notifyAbsent method should probably take the receiver as an argument like this:

   class Object {
     noSuchMethod(invocation) => invocation.notifyAbsent(this);
   }

@floitschG
Copy link
Contributor

Issue #15169 has been merged into this issue.

@lrhn lrhn added Type-Enhancement P3 A lower priority bug or feature request area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. labels Nov 20, 2013
@kevmoo kevmoo added type-enhancement A request for a change that isn't a bug and removed triaged labels Feb 29, 2016
@lrhn lrhn added the core-m label Aug 11, 2017
@floitschG floitschG added core-n and removed core-m labels Aug 29, 2017
@matanlurey matanlurey added the closed-obsolete Closed as the reported issue is no longer relevant label Jun 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-core-library SDK core library issues (core, async, ...); use area-vm or area-web for platform specific libraries. closed-obsolete Closed as the reported issue is no longer relevant core-n P3 A lower priority bug or feature request type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

6 participants