Yeah, we can likely improve error reporting. Basically what happens here is
that internally we do something along the lines of
CallFunction(GetProperty(handler, trapName)) and GetProperty returns undefined,
and the actually error is raised from within CallFunction. Neither parts are
proxy-specific. Both are just generic VM code paths. The error is thrown from
within the engine guts, complaining about undefined not being a function.
Definitely something we can improve, but its not going to happen for Firefox 4
due to scheduling reasons.
Andreas
On Jan 25, 2011, at 9:01 AM, Tom Van Cutsem wrote:
> Re. the cryptic error messages when triggering missing derived or fundamental
> traps: is there any reason why an engine can't create understandable error
> messages for these cases?
>
> An error message such as "non-callable defineProperty trap on proxy" would
> more readily identify the problem than "defineProperty is not a function".
>
> 2011/1/24 Tom Van Cutsem <tomvc...@gmail.com>
> I think there would be a couple of differences between a noop-handler and a
> forwarder-to-an-empty-object.
>
> For one: defining a property on a forwarder-to-an-empty-object would actually
> define the property on the empty object. AIUI, the noop handler would
> silently absorb the assignment. Fixing would also be very different. I think
> forwarding-to-an-empty-object would probably lead to the most intuitive
> behavior. toString() would also work as expected when forwarding to an empty
> object.
>
> One could define a helper function along the lines of:
>
> Proxy.createEmptyHandler = function(proto) {
> proto = proto || null; // maybe the default should be Object.prototype so
> that toString() works as expected
> return new Proxy.Handler(Object.create(proto));
> }
>
> I'm not sure whether this is sufficiently convenient to be worth
> standardizing though.
>
> 2011/1/22 Dave Herman <dher...@mozilla.com>
>
> Not sure; I'll think about it. Though abstracting
> Proxy.Handler(Object.create(null, {})) might in fact be a worthwhile
> convenience.
>
> Dave
>
> "Mark S. Miller" <erig...@google.com> wrote:
>
> >On Fri, Jan 21, 2011 at 2:45 PM, David Herman <dher...@mozilla.com>
> >wrote:
> >
> >> > Should we have a no-op or "sink" standard handler too?
> >>
> >> I think so, yes. Especially since you can use that to build one up
> >that
> >> implements just the other traps you want to implement, and let the
> >others
> >> "fail soft."
> >>
> >
> >How would it be different from
> >
> > new Proxy.Handler(Object.create(null, {}))
> >
> >?
> >
> >Or, depending on how soft you want to fail
> >
> > new Proxy.Handler(null)
> >
> >?
> >
> >If there is a useful difference, I have no objection.
> >
> >
> >>
> >> Dave
> >>
> >>
> >
> >
> >--
> > Cheers,
> > --MarkM
>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
