Repository navigation
Proxies: console.log uses overridden proxy methods by default #12453
Description
Activity
Just fyi,
util.inspect(andconsole.dirindirectly too) has ashowProxyoption that lets you enable displaying the proxy itself, see https://nodejs.org/api/util.html#util_util_inspect_object_options.But I see your point, and I’m not sure whether this should be a bug or not myself. What’s the alternative to passing the error along? Just defaulting to displaying the Proxy target doesn’t seem quite right…
To be honest, it makes sense to me that
console.logshould respect the Proxy (and, as you said, pass the error along). But it doesn't seem like it does so universally:'use strict'; const handler = { get: function(target, prop) { return target[prop] + "baz"; } }; const sandbox = new Proxy({foo: 'bar'}, handler); console.log(sandbox); console.log(sandbox.foo);{ foo: 'bar' } // should this be { foo: 'barbaz' }? barbazPerhaps this is a question for the v8 folks?
Reacted by Daniel BayleyThat latter behaviour is because
util.inspectusesObject.getOwnPropertyDescriptorto get the value, and in your example the proxy doesn’t provide that trap.(Ironically, one of the reasons
util.inspectdoes that is to avoid getters that might throw errors. 😄)Here's an example with the trap added:
'use strict'; const handler = { get: function(target, prop) { return (target && target[prop] && typeof target[prop] == 'string') ? target[prop] + "baz" : target[prop]; }, getOwnPropertyDescriptor: function(target, prop) { let a = Object.getOwnPropertyDescriptor(target, prop); if (a) a.value = this.get(target, prop); return a; } }; const sandbox = new Proxy({foo: 'bar'}, handler); console.log(sandbox); console.log(sandbox.foo);{ foo: 'barbaz' } barbazAt first glance, it seems like everything is working correctly in this example (that doesn't involve error throwing). Perhaps this is just an eccentricity of Node or even Javascript itself? (I'm not sure if the ECMA specification has anything to say about this.)
There are really no consensus on what
console.logshould do in this instance.The way Chrome handles it is always displaying the proxied target in the short one-line view, and providing more information about the proxy once you expand it:
Firefox on the other hand always displays the proxied values, and does not allow introspection of the internal slots of the proxy object:
And in case of thrown errors, it just says
"Error":
FWIW the Console Standard does not say anything about the possibility of throwing either.
Should this remain open?
As far as I see it everything is working as it should. I am closing this therefore.
Linking to #13784 - it's related in the sense that we currently lack a safe way to inspect JS values.
Version: 8.0.0-pre
Platform: Darwin MACHINE_NAME.local 14.3.0 Darwin Kernel Version 14.3.0: Mon Mar 23 11:59:05 PDT 2015; root:xnu-2782.20.48~5/RELEASE_X86_64 x86_64
The following code sample throws an error, due to
console.logusing the proxy's overriddenget- is it supposed to? (FWIW, Chrome's v8 does not throw an error and instead logs the target of theProxy.)