Question about PR #802 - msg_incompat_call_details #1592
Replies: 2 comments 2 replies
-
I came across this while looking into why https://github.com/tc39/test262/blob/main/test/built-ins/BigInt/prototype/toString/prototype-call.js was not passing. In Chrome: > Number.prototype.toString.call(Number.prototype)
<- '0'
> BigInt.prototype.toString.call(BigInt.prototype)
<- Uncaught TypeError: BigInt.prototype.toString requires that 'this' be a BigInt In Rhino: js> Number.prototype.toString.call(Number.prototype)
0
js> BigInt.prototype.toString.call(BigInt.prototype)
0 According to the spec,
But the problem is that |
Beta Was this translation helpful? Give feedback.
-
I think you're right that the impl. details should not leak into the exception like that. Case and possibly a PR? As for the wrong behaviour with BigInt.prototype.toString: don't think it's an inherent probleem in IdScriptable, but rather an issue in the BigInt impl. Case? While on the topic of BigInt: a lot of tests from test262 fail when the feature under testing is used icw BigInt. Wood be great to get some insight into if there's a common denominator between all or many of those failures |
Beta Was this translation helpful? Give feedback.
-
I understand the purpose of #802, and I think it is valuable for troubleshooting Rhino issues, but I wonder if it is inappropriately leaking implementation details to the javascript environment in some cases and a Context flag should control whether or not to display the java class names.
For example, in Rhino I get:
In Chrome I get:
I think a message like what Chrome provides would be much more useful than the message was prior to this PR without leaking java class names.
Beta Was this translation helpful? Give feedback.
All reactions